You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Bill Burcham <bi...@gmail.com> on 2020/02/28 19:42:37 UTC
Let's Deprecate the SECURITY_UDP_DHALGO Configuration Property
I propose we deprecate Geode’s proprietary UDP message privacy algorithm
based on the Diffie-Hellman key exchange protocol. This would deprecate:
ConfigurationProperties.SECURITY_UDP_DHALGO
String DistributionConfig.getSecurityUDPDHAlgo()
void DistributionConfig.setSecurityUDPDHAlgo(String attValue)
DistributionConfig.SECURITY_UDP_DHALGO_NAME
Additionally we’d have to upate documentation to reflect deprecation.
From ConfigurationProperties.java:
Application can set this property to valid symmetric key algorithm, to
encrypt udp messages in Geode. Geode will generate symmetric key using
Diffie-Hellman key exchange algorithm between peers. That key further used
by specified algorithm to encrypt the udp messages.
The property (and the feature) was added mid-2016. Unfortunately it was not
added as an “experimental” feature, so it cannot simply be removed.
Incidentally, the corresponding property for client-server communication,
SECURITY_CLIENT_DHALGO, is already deprecated. It was deprecated in Geode
1.5 in favor of SSL/TLS.
I am proposing deprecating the feature because:
1.
The feature has not proven popular with users.
2.
At least one hard-to-reproduce bug exists in the implementation:
GEODE-6448 <https://issues.apache.org/jira/browse/GEODE-6448>. We’ve
burned a person-week trying to fix the problem (Bruce Schuchardt and me)
and it’s not clear how much more time it will take. If we decide to
deprecate the feature, fixing this problem would be de-prioritized
accordingly.
3.
If we decide, in the future, that UDP message security is required, it
would be better to implement a standard algorithm such as DTLS
<https://tools.ietf.org/html/rfc6347>:
1.
Our algorithm provides only message privacy whereas DTLS provides
privacy, tamper-resistance, and message forgery protection
2.
DTLS is a standard
3.
There is some support for DTLS in the JDK (JEP-219
<https://openjdk.java.net/jeps/219> delivered in JDK 9). It’s not a
complete implementation e.g. guaranteed delivery is a do-it-yourself kit.
Actually implementing DTLS is out of scope for this proposal. Adding DTLS
would be a significant undertaking.
So, how do you feel about me making a GEODE ticket to deprecate the
SECURITY_UDP_DHALGO configuration property?
Re: Let's Deprecate the SECURITY_UDP_DHALGO Configuration Property
Posted by Dan Smith <ds...@pivotal.io>.
>
> @Dan, are you thinking that secured intra-cluster communication needs to
> be deprecated as a whole?
>
> Exactly. We shouldn't be left with "partially secure" intra-cluster
communication, where some stuff goes over TLS and some is plain text.
Setting ssl-enabled-components=cluster without setting security-udp-dhalgo
is like locking your door but leaving the window open.
Our algorithm provides only message privacy whereas DTLS provides privacy,
> tamper-resistance, and message forgery protection
>
I'm not sure that this is true. If you have identified specific
vulnerabilities with geode's UDP encryption they should be reported on
private@geode.apache.org and not dev@geode.apache.org and let's discuss it
there.
That said, I'd love to see us move towards using a more standard protocol
like DTLS.
-Dan
Re: Let's Deprecate the SECURITY_UDP_DHALGO Configuration Property
Posted by Aaron Lindsey <aa...@apache.org>.
+1 to deprecating this feature in 1.12
As to whether we should remove this feature in a minor release, I think that, as Alexander pointed out, it hinges on the question of whether we perceive there to be some security issue in the feature’s implementation.
This statement from the proposal should raise concerns:
> Our algorithm provides only message privacy whereas DTLS provides privacy, tamper-resistance, and message forgery protection
When designing cryptographic protocols we want to guarantee not only privacy of the message, but also the integrity and authenticity. TLS, SSH, and IPSec are examples of commonly used secure protocols which do just that. Users of cryptographic protocols usually expect these guarantees.
I would argue that a protocol such as this does offer a false sense of security in that “security” typically implies not just privacy but also integrity and authenticity.
- Aaron
> On Mar 2, 2020, at 3:30 PM, Alexander Murmann <am...@apache.org> wrote:
>
> I am not sure I am following the argument for removal in a minor version.
> Let's expand the argument and make sure we are all basing this on the same
> assumptions:
>
> Java has removed insecure encryption algorithms in patch releases. This was
> presumably done because it's really fixing a vulnerability, rather than
> removing a useful feature.
>
> Are we in agreement that the UDP encryption as it currently exists does not
> deliver on providing security for data in transit? Bill's original
> description to me indicates that there are problems with the current
> implementation, but not that it creates a false sense of security. There
> seem to exist some intuitions around this, but in order to make the right
> call for our users, we might want to make that more concrete. It would be
> unfortunate to break the promises we make via SemVer unintentionally.
>
> On Mon, Mar 2, 2020 at 11:38 AM Udo Kohlmeyer <ud...@apache.com> wrote:
>
>> I'm back tracking on my suggestion... Got stuck on the "removal" part.
>>
>> +1 -> for deprecation for said feature in 1.12
>>
>> -1 -> for removal until alternative/equivalent replacement has been
>> added (or major version release -- which ever comes first)
>>
>> @Dan, are you thinking that secured intra-cluster communication needs to
>> be deprecated as a whole?
>>
>> --Udo
>>
>> On 3/2/20 10:52 AM, Anthony Baker wrote:
>>> I don’t think regressed is the right word. There was an effort to
>> harden our udp p2p traffic using encryption based on a DH key exchange.
>> I’m not clear on how much that approach actually improved the security of
>> data in motion. And I don’t believe it saw much if any use in practice.
>>>
>>> Anthony
>>>
>>>
>>>> On Mar 2, 2020, at 10:27 AM, Udo Kohlmeyer <uk...@pivotal.io>
>> wrote:
>>>>
>>>> I think that if TCP connections are secured and UDP connections are
>> not, then we've regressed in our security.
>>>>
>>>> Is there a way that we could use DTLS?
>>>>
>>>> --Udo
>>>>
>>>> On 3/2/20 10:21 AM, Dan Smith wrote:
>>>>> Should we deprecate cluster ssl as well? Cluster ssl without udp
>> encryption
>>>>> means that not all P2P traffic will be encrypted. If we don't want to
>>>>> support P2P encryption, it seems like we should deprecate both?
>>>>>
>>>>> -Dan
>>>>>
>>>>> On Fri, Feb 28, 2020 at 1:40 PM Udo Kohlmeyer <uk...@pivotal.io>
>> wrote:
>>>>>
>>>>>> Yes, the proposal was deprecation notice in 1.12 and remove in 1.13..
>>>>>>
>>>>>> That does not leave users much time to react. So if we remove in 1.14,
>>>>>> then users have at least 2 release cycles before we do it.
>>>>>>
>>>>>> --Udo
>>>>>>
>>>>>> On 2/28/20 1:11 PM, Owen Nichols wrote:
>>>>>>> Udo, are you proposing to deprecate in 1.12 and remove in 1.14?
>>>>>>>
>>>>>>>> On Feb 28, 2020, at 1:03 PM, Udo Kohlmeyer <uk...@pivotal.io>
>>>>>> wrote:
>>>>>>>> +1 to adding the deprecation. But I would prefer that we give users
>>>>>> more notice than 3 months.
>>>>>>>> maybe we deprecate it in 1.14
>>>>>>>>
>>>>>>>> --Udo
>>>>>>>>
>>>>>>>> On 2/28/20 1:00 PM, Ernest Burghardt wrote:
>>>>>>>>> +1
>>>>>>>>>
>>>>>>>>> seems reasonable to do this for 1.12 and be ahead of the game,
>> @Owen
>>>>>> would
>>>>>>>>> you please spawn that as a separate release 1.12 thread? thanks, eB
>>>>>>>>>
>>>>>>>>> On Fri, Feb 28, 2020 at 11:56 AM Owen Nichols <onichols@pivotal.io
>>>
>>>>>> wrote:
>>>>>>>>>> +1
>>>>>>>>>>
>>>>>>>>>> We should have done this as soon as SSL/TLS was ready. Better
>> late
>>>>>> than
>>>>>>>>>> never!
>>>>>>>>>>
>>>>>>>>>> While we normally wait until a major release to remove deprecated
>>>>>> stuff,
>>>>>>>>>> there is some precedent for removing insecure encryption
>> algorithms
>>>>>> sooner
>>>>>>>>>> (Java has done this even in patch releases). We should consider
>>>>>> getting
>>>>>>>>>> the deprecation notice into 1.12 and removing in 1.13, rather than
>>>>>> waiting
>>>>>>>>>> for 2.0.
>>>>>>>>>>
>>>>>>>>>>> On Feb 28, 2020, at 11:42 AM, Bill Burcham <
>> bill.burcham@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>> I propose we deprecate Geode’s proprietary UDP message privacy
>>>>>> algorithm
>>>>>>>>>>> based on the Diffie-Hellman key exchange protocol. This would
>>>>>> deprecate:
>>>>>>>>>>> ConfigurationProperties.SECURITY_UDP_DHALGO
>>>>>>>>>>>
>>>>>>>>>>> String DistributionConfig.getSecurityUDPDHAlgo()
>>>>>>>>>>>
>>>>>>>>>>> void DistributionConfig.setSecurityUDPDHAlgo(String attValue)
>>>>>>>>>>> DistributionConfig.SECURITY_UDP_DHALGO_NAME
>>>>>>>>>>>
>>>>>>>>>>> Additionally we’d have to upate documentation to reflect
>> deprecation.
>>>>>>>>>>>
>>>>>>>>>>> From ConfigurationProperties.java:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Application can set this property to valid symmetric key
>> algorithm,
>>>>>> to
>>>>>>>>>>> encrypt udp messages in Geode. Geode will generate symmetric key
>>>>>> using
>>>>>>>>>>> Diffie-Hellman key exchange algorithm between peers. That key
>> further
>>>>>>>>>> used
>>>>>>>>>>> by specified algorithm to encrypt the udp messages.
>>>>>>>>>>>
>>>>>>>>>>> The property (and the feature) was added mid-2016. Unfortunately
>> it
>>>>>> was
>>>>>>>>>> not
>>>>>>>>>>> added as an “experimental” feature, so it cannot simply be
>> removed.
>>>>>>>>>>>
>>>>>>>>>>> Incidentally, the corresponding property for client-server
>>>>>> communication,
>>>>>>>>>>> SECURITY_CLIENT_DHALGO, is already deprecated. It was deprecated
>> in
>>>>>> Geode
>>>>>>>>>>> 1.5 in favor of SSL/TLS.
>>>>>>>>>>>
>>>>>>>>>>> I am proposing deprecating the feature because:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 1.
>>>>>>>>>>>
>>>>>>>>>>> The feature has not proven popular with users.
>>>>>>>>>>> 2.
>>>>>>>>>>>
>>>>>>>>>>> At least one hard-to-reproduce bug exists in the
>> implementation:
>>>>>>>>>>> GEODE-6448 <https://issues.apache.org/jira/browse/GEODE-6448
>>> .
>>>>>> We’ve
>>>>>>>>>>> burned a person-week trying to fix the problem (Bruce
>> Schuchardt
>>>>>> and
>>>>>>>>>> me)
>>>>>>>>>>> and it’s not clear how much more time it will take. If we
>> decide
>>>>>> to
>>>>>>>>>>> deprecate the feature, fixing this problem would be
>> de-prioritized
>>>>>>>>>>> accordingly.
>>>>>>>>>>> 3.
>>>>>>>>>>>
>>>>>>>>>>> If we decide, in the future, that UDP message security is
>>>>>> required, it
>>>>>>>>>>> would be better to implement a standard algorithm such as
>> DTLS
>>>>>>>>>>> <https://tools.ietf.org/html/rfc6347>:
>>>>>>>>>>> 1.
>>>>>>>>>>>
>>>>>>>>>>> Our algorithm provides only message privacy whereas DTLS
>>>>>> provides
>>>>>>>>>>> privacy, tamper-resistance, and message forgery protection
>>>>>>>>>>> 2.
>>>>>>>>>>>
>>>>>>>>>>> DTLS is a standard
>>>>>>>>>>> 3.
>>>>>>>>>>>
>>>>>>>>>>> There is some support for DTLS in the JDK (JEP-219
>>>>>>>>>>> <https://openjdk.java.net/jeps/219> delivered in JDK 9).
>> It’s
>>>>>> not a
>>>>>>>>>>> complete implementation e.g. guaranteed delivery is a
>>>>>>>>>> do-it-yourself kit.
>>>>>>>>>>> Actually implementing DTLS is out of scope for this proposal.
>> Adding
>>>>>> DTLS
>>>>>>>>>>> would be a significant undertaking.
>>>>>>>>>>>
>>>>>>>>>>> So, how do you feel about me making a GEODE ticket to deprecate
>> the
>>>>>>>>>>> SECURITY_UDP_DHALGO configuration property?
>>
Re: Let's Deprecate the SECURITY_UDP_DHALGO Configuration Property
Posted by Alexander Murmann <am...@apache.org>.
I am not sure I am following the argument for removal in a minor version.
Let's expand the argument and make sure we are all basing this on the same
assumptions:
Java has removed insecure encryption algorithms in patch releases. This was
presumably done because it's really fixing a vulnerability, rather than
removing a useful feature.
Are we in agreement that the UDP encryption as it currently exists does not
deliver on providing security for data in transit? Bill's original
description to me indicates that there are problems with the current
implementation, but not that it creates a false sense of security. There
seem to exist some intuitions around this, but in order to make the right
call for our users, we might want to make that more concrete. It would be
unfortunate to break the promises we make via SemVer unintentionally.
On Mon, Mar 2, 2020 at 11:38 AM Udo Kohlmeyer <ud...@apache.com> wrote:
> I'm back tracking on my suggestion... Got stuck on the "removal" part.
>
> +1 -> for deprecation for said feature in 1.12
>
> -1 -> for removal until alternative/equivalent replacement has been
> added (or major version release -- which ever comes first)
>
> @Dan, are you thinking that secured intra-cluster communication needs to
> be deprecated as a whole?
>
> --Udo
>
> On 3/2/20 10:52 AM, Anthony Baker wrote:
> > I don’t think regressed is the right word. There was an effort to
> harden our udp p2p traffic using encryption based on a DH key exchange.
> I’m not clear on how much that approach actually improved the security of
> data in motion. And I don’t believe it saw much if any use in practice.
> >
> > Anthony
> >
> >
> >> On Mar 2, 2020, at 10:27 AM, Udo Kohlmeyer <uk...@pivotal.io>
> wrote:
> >>
> >> I think that if TCP connections are secured and UDP connections are
> not, then we've regressed in our security.
> >>
> >> Is there a way that we could use DTLS?
> >>
> >> --Udo
> >>
> >> On 3/2/20 10:21 AM, Dan Smith wrote:
> >>> Should we deprecate cluster ssl as well? Cluster ssl without udp
> encryption
> >>> means that not all P2P traffic will be encrypted. If we don't want to
> >>> support P2P encryption, it seems like we should deprecate both?
> >>>
> >>> -Dan
> >>>
> >>> On Fri, Feb 28, 2020 at 1:40 PM Udo Kohlmeyer <uk...@pivotal.io>
> wrote:
> >>>
> >>>> Yes, the proposal was deprecation notice in 1.12 and remove in 1.13..
> >>>>
> >>>> That does not leave users much time to react. So if we remove in 1.14,
> >>>> then users have at least 2 release cycles before we do it.
> >>>>
> >>>> --Udo
> >>>>
> >>>> On 2/28/20 1:11 PM, Owen Nichols wrote:
> >>>>> Udo, are you proposing to deprecate in 1.12 and remove in 1.14?
> >>>>>
> >>>>>> On Feb 28, 2020, at 1:03 PM, Udo Kohlmeyer <uk...@pivotal.io>
> >>>> wrote:
> >>>>>> +1 to adding the deprecation. But I would prefer that we give users
> >>>> more notice than 3 months.
> >>>>>> maybe we deprecate it in 1.14
> >>>>>>
> >>>>>> --Udo
> >>>>>>
> >>>>>> On 2/28/20 1:00 PM, Ernest Burghardt wrote:
> >>>>>>> +1
> >>>>>>>
> >>>>>>> seems reasonable to do this for 1.12 and be ahead of the game,
> @Owen
> >>>> would
> >>>>>>> you please spawn that as a separate release 1.12 thread? thanks, eB
> >>>>>>>
> >>>>>>> On Fri, Feb 28, 2020 at 11:56 AM Owen Nichols <onichols@pivotal.io
> >
> >>>> wrote:
> >>>>>>>> +1
> >>>>>>>>
> >>>>>>>> We should have done this as soon as SSL/TLS was ready. Better
> late
> >>>> than
> >>>>>>>> never!
> >>>>>>>>
> >>>>>>>> While we normally wait until a major release to remove deprecated
> >>>> stuff,
> >>>>>>>> there is some precedent for removing insecure encryption
> algorithms
> >>>> sooner
> >>>>>>>> (Java has done this even in patch releases). We should consider
> >>>> getting
> >>>>>>>> the deprecation notice into 1.12 and removing in 1.13, rather than
> >>>> waiting
> >>>>>>>> for 2.0.
> >>>>>>>>
> >>>>>>>>> On Feb 28, 2020, at 11:42 AM, Bill Burcham <
> bill.burcham@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>> I propose we deprecate Geode’s proprietary UDP message privacy
> >>>> algorithm
> >>>>>>>>> based on the Diffie-Hellman key exchange protocol. This would
> >>>> deprecate:
> >>>>>>>>> ConfigurationProperties.SECURITY_UDP_DHALGO
> >>>>>>>>>
> >>>>>>>>> String DistributionConfig.getSecurityUDPDHAlgo()
> >>>>>>>>>
> >>>>>>>>> void DistributionConfig.setSecurityUDPDHAlgo(String attValue)
> >>>>>>>>> DistributionConfig.SECURITY_UDP_DHALGO_NAME
> >>>>>>>>>
> >>>>>>>>> Additionally we’d have to upate documentation to reflect
> deprecation.
> >>>>>>>>>
> >>>>>>>>> From ConfigurationProperties.java:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Application can set this property to valid symmetric key
> algorithm,
> >>>> to
> >>>>>>>>> encrypt udp messages in Geode. Geode will generate symmetric key
> >>>> using
> >>>>>>>>> Diffie-Hellman key exchange algorithm between peers. That key
> further
> >>>>>>>> used
> >>>>>>>>> by specified algorithm to encrypt the udp messages.
> >>>>>>>>>
> >>>>>>>>> The property (and the feature) was added mid-2016. Unfortunately
> it
> >>>> was
> >>>>>>>> not
> >>>>>>>>> added as an “experimental” feature, so it cannot simply be
> removed.
> >>>>>>>>>
> >>>>>>>>> Incidentally, the corresponding property for client-server
> >>>> communication,
> >>>>>>>>> SECURITY_CLIENT_DHALGO, is already deprecated. It was deprecated
> in
> >>>> Geode
> >>>>>>>>> 1.5 in favor of SSL/TLS.
> >>>>>>>>>
> >>>>>>>>> I am proposing deprecating the feature because:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> 1.
> >>>>>>>>>
> >>>>>>>>> The feature has not proven popular with users.
> >>>>>>>>> 2.
> >>>>>>>>>
> >>>>>>>>> At least one hard-to-reproduce bug exists in the
> implementation:
> >>>>>>>>> GEODE-6448 <https://issues.apache.org/jira/browse/GEODE-6448
> >.
> >>>> We’ve
> >>>>>>>>> burned a person-week trying to fix the problem (Bruce
> Schuchardt
> >>>> and
> >>>>>>>> me)
> >>>>>>>>> and it’s not clear how much more time it will take. If we
> decide
> >>>> to
> >>>>>>>>> deprecate the feature, fixing this problem would be
> de-prioritized
> >>>>>>>>> accordingly.
> >>>>>>>>> 3.
> >>>>>>>>>
> >>>>>>>>> If we decide, in the future, that UDP message security is
> >>>> required, it
> >>>>>>>>> would be better to implement a standard algorithm such as
> DTLS
> >>>>>>>>> <https://tools.ietf.org/html/rfc6347>:
> >>>>>>>>> 1.
> >>>>>>>>>
> >>>>>>>>> Our algorithm provides only message privacy whereas DTLS
> >>>> provides
> >>>>>>>>> privacy, tamper-resistance, and message forgery protection
> >>>>>>>>> 2.
> >>>>>>>>>
> >>>>>>>>> DTLS is a standard
> >>>>>>>>> 3.
> >>>>>>>>>
> >>>>>>>>> There is some support for DTLS in the JDK (JEP-219
> >>>>>>>>> <https://openjdk.java.net/jeps/219> delivered in JDK 9).
> It’s
> >>>> not a
> >>>>>>>>> complete implementation e.g. guaranteed delivery is a
> >>>>>>>> do-it-yourself kit.
> >>>>>>>>> Actually implementing DTLS is out of scope for this proposal.
> Adding
> >>>> DTLS
> >>>>>>>>> would be a significant undertaking.
> >>>>>>>>>
> >>>>>>>>> So, how do you feel about me making a GEODE ticket to deprecate
> the
> >>>>>>>>> SECURITY_UDP_DHALGO configuration property?
>
Re: Let's Deprecate the SECURITY_UDP_DHALGO Configuration Property
Posted by Udo Kohlmeyer <ud...@apache.com>.
I'm back tracking on my suggestion... Got stuck on the "removal" part.
+1 -> for deprecation for said feature in 1.12
-1 -> for removal until alternative/equivalent replacement has been
added (or major version release -- which ever comes first)
@Dan, are you thinking that secured intra-cluster communication needs to
be deprecated as a whole?
--Udo
On 3/2/20 10:52 AM, Anthony Baker wrote:
> I don’t think regressed is the right word. There was an effort to harden our udp p2p traffic using encryption based on a DH key exchange. I’m not clear on how much that approach actually improved the security of data in motion. And I don’t believe it saw much if any use in practice.
>
> Anthony
>
>
>> On Mar 2, 2020, at 10:27 AM, Udo Kohlmeyer <uk...@pivotal.io> wrote:
>>
>> I think that if TCP connections are secured and UDP connections are not, then we've regressed in our security.
>>
>> Is there a way that we could use DTLS?
>>
>> --Udo
>>
>> On 3/2/20 10:21 AM, Dan Smith wrote:
>>> Should we deprecate cluster ssl as well? Cluster ssl without udp encryption
>>> means that not all P2P traffic will be encrypted. If we don't want to
>>> support P2P encryption, it seems like we should deprecate both?
>>>
>>> -Dan
>>>
>>> On Fri, Feb 28, 2020 at 1:40 PM Udo Kohlmeyer <uk...@pivotal.io> wrote:
>>>
>>>> Yes, the proposal was deprecation notice in 1.12 and remove in 1.13..
>>>>
>>>> That does not leave users much time to react. So if we remove in 1.14,
>>>> then users have at least 2 release cycles before we do it.
>>>>
>>>> --Udo
>>>>
>>>> On 2/28/20 1:11 PM, Owen Nichols wrote:
>>>>> Udo, are you proposing to deprecate in 1.12 and remove in 1.14?
>>>>>
>>>>>> On Feb 28, 2020, at 1:03 PM, Udo Kohlmeyer <uk...@pivotal.io>
>>>> wrote:
>>>>>> +1 to adding the deprecation. But I would prefer that we give users
>>>> more notice than 3 months.
>>>>>> maybe we deprecate it in 1.14
>>>>>>
>>>>>> --Udo
>>>>>>
>>>>>> On 2/28/20 1:00 PM, Ernest Burghardt wrote:
>>>>>>> +1
>>>>>>>
>>>>>>> seems reasonable to do this for 1.12 and be ahead of the game, @Owen
>>>> would
>>>>>>> you please spawn that as a separate release 1.12 thread? thanks, eB
>>>>>>>
>>>>>>> On Fri, Feb 28, 2020 at 11:56 AM Owen Nichols <on...@pivotal.io>
>>>> wrote:
>>>>>>>> +1
>>>>>>>>
>>>>>>>> We should have done this as soon as SSL/TLS was ready. Better late
>>>> than
>>>>>>>> never!
>>>>>>>>
>>>>>>>> While we normally wait until a major release to remove deprecated
>>>> stuff,
>>>>>>>> there is some precedent for removing insecure encryption algorithms
>>>> sooner
>>>>>>>> (Java has done this even in patch releases). We should consider
>>>> getting
>>>>>>>> the deprecation notice into 1.12 and removing in 1.13, rather than
>>>> waiting
>>>>>>>> for 2.0.
>>>>>>>>
>>>>>>>>> On Feb 28, 2020, at 11:42 AM, Bill Burcham <bi...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>> I propose we deprecate Geode’s proprietary UDP message privacy
>>>> algorithm
>>>>>>>>> based on the Diffie-Hellman key exchange protocol. This would
>>>> deprecate:
>>>>>>>>> ConfigurationProperties.SECURITY_UDP_DHALGO
>>>>>>>>>
>>>>>>>>> String DistributionConfig.getSecurityUDPDHAlgo()
>>>>>>>>>
>>>>>>>>> void DistributionConfig.setSecurityUDPDHAlgo(String attValue)
>>>>>>>>> DistributionConfig.SECURITY_UDP_DHALGO_NAME
>>>>>>>>>
>>>>>>>>> Additionally we’d have to upate documentation to reflect deprecation.
>>>>>>>>>
>>>>>>>>> From ConfigurationProperties.java:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Application can set this property to valid symmetric key algorithm,
>>>> to
>>>>>>>>> encrypt udp messages in Geode. Geode will generate symmetric key
>>>> using
>>>>>>>>> Diffie-Hellman key exchange algorithm between peers. That key further
>>>>>>>> used
>>>>>>>>> by specified algorithm to encrypt the udp messages.
>>>>>>>>>
>>>>>>>>> The property (and the feature) was added mid-2016. Unfortunately it
>>>> was
>>>>>>>> not
>>>>>>>>> added as an “experimental” feature, so it cannot simply be removed.
>>>>>>>>>
>>>>>>>>> Incidentally, the corresponding property for client-server
>>>> communication,
>>>>>>>>> SECURITY_CLIENT_DHALGO, is already deprecated. It was deprecated in
>>>> Geode
>>>>>>>>> 1.5 in favor of SSL/TLS.
>>>>>>>>>
>>>>>>>>> I am proposing deprecating the feature because:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 1.
>>>>>>>>>
>>>>>>>>> The feature has not proven popular with users.
>>>>>>>>> 2.
>>>>>>>>>
>>>>>>>>> At least one hard-to-reproduce bug exists in the implementation:
>>>>>>>>> GEODE-6448 <https://issues.apache.org/jira/browse/GEODE-6448>.
>>>> We’ve
>>>>>>>>> burned a person-week trying to fix the problem (Bruce Schuchardt
>>>> and
>>>>>>>> me)
>>>>>>>>> and it’s not clear how much more time it will take. If we decide
>>>> to
>>>>>>>>> deprecate the feature, fixing this problem would be de-prioritized
>>>>>>>>> accordingly.
>>>>>>>>> 3.
>>>>>>>>>
>>>>>>>>> If we decide, in the future, that UDP message security is
>>>> required, it
>>>>>>>>> would be better to implement a standard algorithm such as DTLS
>>>>>>>>> <https://tools.ietf.org/html/rfc6347>:
>>>>>>>>> 1.
>>>>>>>>>
>>>>>>>>> Our algorithm provides only message privacy whereas DTLS
>>>> provides
>>>>>>>>> privacy, tamper-resistance, and message forgery protection
>>>>>>>>> 2.
>>>>>>>>>
>>>>>>>>> DTLS is a standard
>>>>>>>>> 3.
>>>>>>>>>
>>>>>>>>> There is some support for DTLS in the JDK (JEP-219
>>>>>>>>> <https://openjdk.java.net/jeps/219> delivered in JDK 9). It’s
>>>> not a
>>>>>>>>> complete implementation e.g. guaranteed delivery is a
>>>>>>>> do-it-yourself kit.
>>>>>>>>> Actually implementing DTLS is out of scope for this proposal. Adding
>>>> DTLS
>>>>>>>>> would be a significant undertaking.
>>>>>>>>>
>>>>>>>>> So, how do you feel about me making a GEODE ticket to deprecate the
>>>>>>>>> SECURITY_UDP_DHALGO configuration property?
Re: Let's Deprecate the SECURITY_UDP_DHALGO Configuration Property
Posted by Anthony Baker <ab...@pivotal.io>.
I don’t think regressed is the right word. There was an effort to harden our udp p2p traffic using encryption based on a DH key exchange. I’m not clear on how much that approach actually improved the security of data in motion. And I don’t believe it saw much if any use in practice.
Anthony
> On Mar 2, 2020, at 10:27 AM, Udo Kohlmeyer <uk...@pivotal.io> wrote:
>
> I think that if TCP connections are secured and UDP connections are not, then we've regressed in our security.
>
> Is there a way that we could use DTLS?
>
> --Udo
>
> On 3/2/20 10:21 AM, Dan Smith wrote:
>> Should we deprecate cluster ssl as well? Cluster ssl without udp encryption
>> means that not all P2P traffic will be encrypted. If we don't want to
>> support P2P encryption, it seems like we should deprecate both?
>>
>> -Dan
>>
>> On Fri, Feb 28, 2020 at 1:40 PM Udo Kohlmeyer <uk...@pivotal.io> wrote:
>>
>>> Yes, the proposal was deprecation notice in 1.12 and remove in 1.13..
>>>
>>> That does not leave users much time to react. So if we remove in 1.14,
>>> then users have at least 2 release cycles before we do it.
>>>
>>> --Udo
>>>
>>> On 2/28/20 1:11 PM, Owen Nichols wrote:
>>>> Udo, are you proposing to deprecate in 1.12 and remove in 1.14?
>>>>
>>>>> On Feb 28, 2020, at 1:03 PM, Udo Kohlmeyer <uk...@pivotal.io>
>>> wrote:
>>>>> +1 to adding the deprecation. But I would prefer that we give users
>>> more notice than 3 months.
>>>>> maybe we deprecate it in 1.14
>>>>>
>>>>> --Udo
>>>>>
>>>>> On 2/28/20 1:00 PM, Ernest Burghardt wrote:
>>>>>> +1
>>>>>>
>>>>>> seems reasonable to do this for 1.12 and be ahead of the game, @Owen
>>> would
>>>>>> you please spawn that as a separate release 1.12 thread? thanks, eB
>>>>>>
>>>>>> On Fri, Feb 28, 2020 at 11:56 AM Owen Nichols <on...@pivotal.io>
>>> wrote:
>>>>>>> +1
>>>>>>>
>>>>>>> We should have done this as soon as SSL/TLS was ready. Better late
>>> than
>>>>>>> never!
>>>>>>>
>>>>>>> While we normally wait until a major release to remove deprecated
>>> stuff,
>>>>>>> there is some precedent for removing insecure encryption algorithms
>>> sooner
>>>>>>> (Java has done this even in patch releases). We should consider
>>> getting
>>>>>>> the deprecation notice into 1.12 and removing in 1.13, rather than
>>> waiting
>>>>>>> for 2.0.
>>>>>>>
>>>>>>>> On Feb 28, 2020, at 11:42 AM, Bill Burcham <bi...@gmail.com>
>>>>>>> wrote:
>>>>>>>> I propose we deprecate Geode’s proprietary UDP message privacy
>>> algorithm
>>>>>>>> based on the Diffie-Hellman key exchange protocol. This would
>>> deprecate:
>>>>>>>> ConfigurationProperties.SECURITY_UDP_DHALGO
>>>>>>>>
>>>>>>>> String DistributionConfig.getSecurityUDPDHAlgo()
>>>>>>>>
>>>>>>>> void DistributionConfig.setSecurityUDPDHAlgo(String attValue)
>>>>>>>> DistributionConfig.SECURITY_UDP_DHALGO_NAME
>>>>>>>>
>>>>>>>> Additionally we’d have to upate documentation to reflect deprecation.
>>>>>>>>
>>>>>>>> From ConfigurationProperties.java:
>>>>>>>>
>>>>>>>>
>>>>>>>> Application can set this property to valid symmetric key algorithm,
>>> to
>>>>>>>> encrypt udp messages in Geode. Geode will generate symmetric key
>>> using
>>>>>>>> Diffie-Hellman key exchange algorithm between peers. That key further
>>>>>>> used
>>>>>>>> by specified algorithm to encrypt the udp messages.
>>>>>>>>
>>>>>>>> The property (and the feature) was added mid-2016. Unfortunately it
>>> was
>>>>>>> not
>>>>>>>> added as an “experimental” feature, so it cannot simply be removed.
>>>>>>>>
>>>>>>>> Incidentally, the corresponding property for client-server
>>> communication,
>>>>>>>> SECURITY_CLIENT_DHALGO, is already deprecated. It was deprecated in
>>> Geode
>>>>>>>> 1.5 in favor of SSL/TLS.
>>>>>>>>
>>>>>>>> I am proposing deprecating the feature because:
>>>>>>>>
>>>>>>>>
>>>>>>>> 1.
>>>>>>>>
>>>>>>>> The feature has not proven popular with users.
>>>>>>>> 2.
>>>>>>>>
>>>>>>>> At least one hard-to-reproduce bug exists in the implementation:
>>>>>>>> GEODE-6448 <https://issues.apache.org/jira/browse/GEODE-6448>.
>>> We’ve
>>>>>>>> burned a person-week trying to fix the problem (Bruce Schuchardt
>>> and
>>>>>>> me)
>>>>>>>> and it’s not clear how much more time it will take. If we decide
>>> to
>>>>>>>> deprecate the feature, fixing this problem would be de-prioritized
>>>>>>>> accordingly.
>>>>>>>> 3.
>>>>>>>>
>>>>>>>> If we decide, in the future, that UDP message security is
>>> required, it
>>>>>>>> would be better to implement a standard algorithm such as DTLS
>>>>>>>> <https://tools.ietf.org/html/rfc6347>:
>>>>>>>> 1.
>>>>>>>>
>>>>>>>> Our algorithm provides only message privacy whereas DTLS
>>> provides
>>>>>>>> privacy, tamper-resistance, and message forgery protection
>>>>>>>> 2.
>>>>>>>>
>>>>>>>> DTLS is a standard
>>>>>>>> 3.
>>>>>>>>
>>>>>>>> There is some support for DTLS in the JDK (JEP-219
>>>>>>>> <https://openjdk.java.net/jeps/219> delivered in JDK 9). It’s
>>> not a
>>>>>>>> complete implementation e.g. guaranteed delivery is a
>>>>>>> do-it-yourself kit.
>>>>>>>> Actually implementing DTLS is out of scope for this proposal. Adding
>>> DTLS
>>>>>>>> would be a significant undertaking.
>>>>>>>>
>>>>>>>> So, how do you feel about me making a GEODE ticket to deprecate the
>>>>>>>> SECURITY_UDP_DHALGO configuration property?
Re: Let's Deprecate the SECURITY_UDP_DHALGO Configuration Property
Posted by Udo Kohlmeyer <uk...@pivotal.io>.
I think that if TCP connections are secured and UDP connections are not,
then we've regressed in our security.
Is there a way that we could use DTLS?
--Udo
On 3/2/20 10:21 AM, Dan Smith wrote:
> Should we deprecate cluster ssl as well? Cluster ssl without udp encryption
> means that not all P2P traffic will be encrypted. If we don't want to
> support P2P encryption, it seems like we should deprecate both?
>
> -Dan
>
> On Fri, Feb 28, 2020 at 1:40 PM Udo Kohlmeyer <uk...@pivotal.io> wrote:
>
>> Yes, the proposal was deprecation notice in 1.12 and remove in 1.13..
>>
>> That does not leave users much time to react. So if we remove in 1.14,
>> then users have at least 2 release cycles before we do it.
>>
>> --Udo
>>
>> On 2/28/20 1:11 PM, Owen Nichols wrote:
>>> Udo, are you proposing to deprecate in 1.12 and remove in 1.14?
>>>
>>>> On Feb 28, 2020, at 1:03 PM, Udo Kohlmeyer <uk...@pivotal.io>
>> wrote:
>>>> +1 to adding the deprecation. But I would prefer that we give users
>> more notice than 3 months.
>>>> maybe we deprecate it in 1.14
>>>>
>>>> --Udo
>>>>
>>>> On 2/28/20 1:00 PM, Ernest Burghardt wrote:
>>>>> +1
>>>>>
>>>>> seems reasonable to do this for 1.12 and be ahead of the game, @Owen
>> would
>>>>> you please spawn that as a separate release 1.12 thread? thanks, eB
>>>>>
>>>>> On Fri, Feb 28, 2020 at 11:56 AM Owen Nichols <on...@pivotal.io>
>> wrote:
>>>>>> +1
>>>>>>
>>>>>> We should have done this as soon as SSL/TLS was ready. Better late
>> than
>>>>>> never!
>>>>>>
>>>>>> While we normally wait until a major release to remove deprecated
>> stuff,
>>>>>> there is some precedent for removing insecure encryption algorithms
>> sooner
>>>>>> (Java has done this even in patch releases). We should consider
>> getting
>>>>>> the deprecation notice into 1.12 and removing in 1.13, rather than
>> waiting
>>>>>> for 2.0.
>>>>>>
>>>>>>> On Feb 28, 2020, at 11:42 AM, Bill Burcham <bi...@gmail.com>
>>>>>> wrote:
>>>>>>> I propose we deprecate Geode’s proprietary UDP message privacy
>> algorithm
>>>>>>> based on the Diffie-Hellman key exchange protocol. This would
>> deprecate:
>>>>>>> ConfigurationProperties.SECURITY_UDP_DHALGO
>>>>>>>
>>>>>>> String DistributionConfig.getSecurityUDPDHAlgo()
>>>>>>>
>>>>>>> void DistributionConfig.setSecurityUDPDHAlgo(String attValue)
>>>>>>> DistributionConfig.SECURITY_UDP_DHALGO_NAME
>>>>>>>
>>>>>>> Additionally we’d have to upate documentation to reflect deprecation.
>>>>>>>
>>>>>>> From ConfigurationProperties.java:
>>>>>>>
>>>>>>>
>>>>>>> Application can set this property to valid symmetric key algorithm,
>> to
>>>>>>> encrypt udp messages in Geode. Geode will generate symmetric key
>> using
>>>>>>> Diffie-Hellman key exchange algorithm between peers. That key further
>>>>>> used
>>>>>>> by specified algorithm to encrypt the udp messages.
>>>>>>>
>>>>>>> The property (and the feature) was added mid-2016. Unfortunately it
>> was
>>>>>> not
>>>>>>> added as an “experimental” feature, so it cannot simply be removed.
>>>>>>>
>>>>>>> Incidentally, the corresponding property for client-server
>> communication,
>>>>>>> SECURITY_CLIENT_DHALGO, is already deprecated. It was deprecated in
>> Geode
>>>>>>> 1.5 in favor of SSL/TLS.
>>>>>>>
>>>>>>> I am proposing deprecating the feature because:
>>>>>>>
>>>>>>>
>>>>>>> 1.
>>>>>>>
>>>>>>> The feature has not proven popular with users.
>>>>>>> 2.
>>>>>>>
>>>>>>> At least one hard-to-reproduce bug exists in the implementation:
>>>>>>> GEODE-6448 <https://issues.apache.org/jira/browse/GEODE-6448>.
>> We’ve
>>>>>>> burned a person-week trying to fix the problem (Bruce Schuchardt
>> and
>>>>>> me)
>>>>>>> and it’s not clear how much more time it will take. If we decide
>> to
>>>>>>> deprecate the feature, fixing this problem would be de-prioritized
>>>>>>> accordingly.
>>>>>>> 3.
>>>>>>>
>>>>>>> If we decide, in the future, that UDP message security is
>> required, it
>>>>>>> would be better to implement a standard algorithm such as DTLS
>>>>>>> <https://tools.ietf.org/html/rfc6347>:
>>>>>>> 1.
>>>>>>>
>>>>>>> Our algorithm provides only message privacy whereas DTLS
>> provides
>>>>>>> privacy, tamper-resistance, and message forgery protection
>>>>>>> 2.
>>>>>>>
>>>>>>> DTLS is a standard
>>>>>>> 3.
>>>>>>>
>>>>>>> There is some support for DTLS in the JDK (JEP-219
>>>>>>> <https://openjdk.java.net/jeps/219> delivered in JDK 9). It’s
>> not a
>>>>>>> complete implementation e.g. guaranteed delivery is a
>>>>>> do-it-yourself kit.
>>>>>>> Actually implementing DTLS is out of scope for this proposal. Adding
>> DTLS
>>>>>>> would be a significant undertaking.
>>>>>>>
>>>>>>> So, how do you feel about me making a GEODE ticket to deprecate the
>>>>>>> SECURITY_UDP_DHALGO configuration property?
Re: Let's Deprecate the SECURITY_UDP_DHALGO Configuration Property
Posted by Dan Smith <ds...@pivotal.io>.
Should we deprecate cluster ssl as well? Cluster ssl without udp encryption
means that not all P2P traffic will be encrypted. If we don't want to
support P2P encryption, it seems like we should deprecate both?
-Dan
On Fri, Feb 28, 2020 at 1:40 PM Udo Kohlmeyer <uk...@pivotal.io> wrote:
> Yes, the proposal was deprecation notice in 1.12 and remove in 1.13..
>
> That does not leave users much time to react. So if we remove in 1.14,
> then users have at least 2 release cycles before we do it.
>
> --Udo
>
> On 2/28/20 1:11 PM, Owen Nichols wrote:
> > Udo, are you proposing to deprecate in 1.12 and remove in 1.14?
> >
> >> On Feb 28, 2020, at 1:03 PM, Udo Kohlmeyer <uk...@pivotal.io>
> wrote:
> >>
> >> +1 to adding the deprecation. But I would prefer that we give users
> more notice than 3 months.
> >>
> >> maybe we deprecate it in 1.14
> >>
> >> --Udo
> >>
> >> On 2/28/20 1:00 PM, Ernest Burghardt wrote:
> >>> +1
> >>>
> >>> seems reasonable to do this for 1.12 and be ahead of the game, @Owen
> would
> >>> you please spawn that as a separate release 1.12 thread? thanks, eB
> >>>
> >>> On Fri, Feb 28, 2020 at 11:56 AM Owen Nichols <on...@pivotal.io>
> wrote:
> >>>
> >>>> +1
> >>>>
> >>>> We should have done this as soon as SSL/TLS was ready. Better late
> than
> >>>> never!
> >>>>
> >>>> While we normally wait until a major release to remove deprecated
> stuff,
> >>>> there is some precedent for removing insecure encryption algorithms
> sooner
> >>>> (Java has done this even in patch releases). We should consider
> getting
> >>>> the deprecation notice into 1.12 and removing in 1.13, rather than
> waiting
> >>>> for 2.0.
> >>>>
> >>>>> On Feb 28, 2020, at 11:42 AM, Bill Burcham <bi...@gmail.com>
> >>>> wrote:
> >>>>> I propose we deprecate Geode’s proprietary UDP message privacy
> algorithm
> >>>>> based on the Diffie-Hellman key exchange protocol. This would
> deprecate:
> >>>>>
> >>>>> ConfigurationProperties.SECURITY_UDP_DHALGO
> >>>>>
> >>>>> String DistributionConfig.getSecurityUDPDHAlgo()
> >>>>>
> >>>>> void DistributionConfig.setSecurityUDPDHAlgo(String attValue)
> >>>>> DistributionConfig.SECURITY_UDP_DHALGO_NAME
> >>>>>
> >>>>> Additionally we’d have to upate documentation to reflect deprecation.
> >>>>>
> >>>>> From ConfigurationProperties.java:
> >>>>>
> >>>>>
> >>>>> Application can set this property to valid symmetric key algorithm,
> to
> >>>>> encrypt udp messages in Geode. Geode will generate symmetric key
> using
> >>>>> Diffie-Hellman key exchange algorithm between peers. That key further
> >>>> used
> >>>>> by specified algorithm to encrypt the udp messages.
> >>>>>
> >>>>> The property (and the feature) was added mid-2016. Unfortunately it
> was
> >>>> not
> >>>>> added as an “experimental” feature, so it cannot simply be removed.
> >>>>>
> >>>>> Incidentally, the corresponding property for client-server
> communication,
> >>>>> SECURITY_CLIENT_DHALGO, is already deprecated. It was deprecated in
> Geode
> >>>>> 1.5 in favor of SSL/TLS.
> >>>>>
> >>>>> I am proposing deprecating the feature because:
> >>>>>
> >>>>>
> >>>>> 1.
> >>>>>
> >>>>> The feature has not proven popular with users.
> >>>>> 2.
> >>>>>
> >>>>> At least one hard-to-reproduce bug exists in the implementation:
> >>>>> GEODE-6448 <https://issues.apache.org/jira/browse/GEODE-6448>.
> We’ve
> >>>>> burned a person-week trying to fix the problem (Bruce Schuchardt
> and
> >>>> me)
> >>>>> and it’s not clear how much more time it will take. If we decide
> to
> >>>>> deprecate the feature, fixing this problem would be de-prioritized
> >>>>> accordingly.
> >>>>> 3.
> >>>>>
> >>>>> If we decide, in the future, that UDP message security is
> required, it
> >>>>> would be better to implement a standard algorithm such as DTLS
> >>>>> <https://tools.ietf.org/html/rfc6347>:
> >>>>> 1.
> >>>>>
> >>>>> Our algorithm provides only message privacy whereas DTLS
> provides
> >>>>> privacy, tamper-resistance, and message forgery protection
> >>>>> 2.
> >>>>>
> >>>>> DTLS is a standard
> >>>>> 3.
> >>>>>
> >>>>> There is some support for DTLS in the JDK (JEP-219
> >>>>> <https://openjdk.java.net/jeps/219> delivered in JDK 9). It’s
> not a
> >>>>> complete implementation e.g. guaranteed delivery is a
> >>>> do-it-yourself kit.
> >>>>> Actually implementing DTLS is out of scope for this proposal. Adding
> DTLS
> >>>>> would be a significant undertaking.
> >>>>>
> >>>>> So, how do you feel about me making a GEODE ticket to deprecate the
> >>>>> SECURITY_UDP_DHALGO configuration property?
>
Re: Let's Deprecate the SECURITY_UDP_DHALGO Configuration Property
Posted by Udo Kohlmeyer <uk...@pivotal.io>.
Yes, the proposal was deprecation notice in 1.12 and remove in 1.13..
That does not leave users much time to react. So if we remove in 1.14,
then users have at least 2 release cycles before we do it.
--Udo
On 2/28/20 1:11 PM, Owen Nichols wrote:
> Udo, are you proposing to deprecate in 1.12 and remove in 1.14?
>
>> On Feb 28, 2020, at 1:03 PM, Udo Kohlmeyer <uk...@pivotal.io> wrote:
>>
>> +1 to adding the deprecation. But I would prefer that we give users more notice than 3 months.
>>
>> maybe we deprecate it in 1.14
>>
>> --Udo
>>
>> On 2/28/20 1:00 PM, Ernest Burghardt wrote:
>>> +1
>>>
>>> seems reasonable to do this for 1.12 and be ahead of the game, @Owen would
>>> you please spawn that as a separate release 1.12 thread? thanks, eB
>>>
>>> On Fri, Feb 28, 2020 at 11:56 AM Owen Nichols <on...@pivotal.io> wrote:
>>>
>>>> +1
>>>>
>>>> We should have done this as soon as SSL/TLS was ready. Better late than
>>>> never!
>>>>
>>>> While we normally wait until a major release to remove deprecated stuff,
>>>> there is some precedent for removing insecure encryption algorithms sooner
>>>> (Java has done this even in patch releases). We should consider getting
>>>> the deprecation notice into 1.12 and removing in 1.13, rather than waiting
>>>> for 2.0.
>>>>
>>>>> On Feb 28, 2020, at 11:42 AM, Bill Burcham <bi...@gmail.com>
>>>> wrote:
>>>>> I propose we deprecate Geode’s proprietary UDP message privacy algorithm
>>>>> based on the Diffie-Hellman key exchange protocol. This would deprecate:
>>>>>
>>>>> ConfigurationProperties.SECURITY_UDP_DHALGO
>>>>>
>>>>> String DistributionConfig.getSecurityUDPDHAlgo()
>>>>>
>>>>> void DistributionConfig.setSecurityUDPDHAlgo(String attValue)
>>>>> DistributionConfig.SECURITY_UDP_DHALGO_NAME
>>>>>
>>>>> Additionally we’d have to upate documentation to reflect deprecation.
>>>>>
>>>>> From ConfigurationProperties.java:
>>>>>
>>>>>
>>>>> Application can set this property to valid symmetric key algorithm, to
>>>>> encrypt udp messages in Geode. Geode will generate symmetric key using
>>>>> Diffie-Hellman key exchange algorithm between peers. That key further
>>>> used
>>>>> by specified algorithm to encrypt the udp messages.
>>>>>
>>>>> The property (and the feature) was added mid-2016. Unfortunately it was
>>>> not
>>>>> added as an “experimental” feature, so it cannot simply be removed.
>>>>>
>>>>> Incidentally, the corresponding property for client-server communication,
>>>>> SECURITY_CLIENT_DHALGO, is already deprecated. It was deprecated in Geode
>>>>> 1.5 in favor of SSL/TLS.
>>>>>
>>>>> I am proposing deprecating the feature because:
>>>>>
>>>>>
>>>>> 1.
>>>>>
>>>>> The feature has not proven popular with users.
>>>>> 2.
>>>>>
>>>>> At least one hard-to-reproduce bug exists in the implementation:
>>>>> GEODE-6448 <https://issues.apache.org/jira/browse/GEODE-6448>. We’ve
>>>>> burned a person-week trying to fix the problem (Bruce Schuchardt and
>>>> me)
>>>>> and it’s not clear how much more time it will take. If we decide to
>>>>> deprecate the feature, fixing this problem would be de-prioritized
>>>>> accordingly.
>>>>> 3.
>>>>>
>>>>> If we decide, in the future, that UDP message security is required, it
>>>>> would be better to implement a standard algorithm such as DTLS
>>>>> <https://tools.ietf.org/html/rfc6347>:
>>>>> 1.
>>>>>
>>>>> Our algorithm provides only message privacy whereas DTLS provides
>>>>> privacy, tamper-resistance, and message forgery protection
>>>>> 2.
>>>>>
>>>>> DTLS is a standard
>>>>> 3.
>>>>>
>>>>> There is some support for DTLS in the JDK (JEP-219
>>>>> <https://openjdk.java.net/jeps/219> delivered in JDK 9). It’s not a
>>>>> complete implementation e.g. guaranteed delivery is a
>>>> do-it-yourself kit.
>>>>> Actually implementing DTLS is out of scope for this proposal. Adding DTLS
>>>>> would be a significant undertaking.
>>>>>
>>>>> So, how do you feel about me making a GEODE ticket to deprecate the
>>>>> SECURITY_UDP_DHALGO configuration property?
Re: Let's Deprecate the SECURITY_UDP_DHALGO Configuration Property
Posted by Owen Nichols <on...@pivotal.io>.
Udo, are you proposing to deprecate in 1.12 and remove in 1.14?
> On Feb 28, 2020, at 1:03 PM, Udo Kohlmeyer <uk...@pivotal.io> wrote:
>
> +1 to adding the deprecation. But I would prefer that we give users more notice than 3 months.
>
> maybe we deprecate it in 1.14
>
> --Udo
>
> On 2/28/20 1:00 PM, Ernest Burghardt wrote:
>> +1
>>
>> seems reasonable to do this for 1.12 and be ahead of the game, @Owen would
>> you please spawn that as a separate release 1.12 thread? thanks, eB
>>
>> On Fri, Feb 28, 2020 at 11:56 AM Owen Nichols <on...@pivotal.io> wrote:
>>
>>> +1
>>>
>>> We should have done this as soon as SSL/TLS was ready. Better late than
>>> never!
>>>
>>> While we normally wait until a major release to remove deprecated stuff,
>>> there is some precedent for removing insecure encryption algorithms sooner
>>> (Java has done this even in patch releases). We should consider getting
>>> the deprecation notice into 1.12 and removing in 1.13, rather than waiting
>>> for 2.0.
>>>
>>>> On Feb 28, 2020, at 11:42 AM, Bill Burcham <bi...@gmail.com>
>>> wrote:
>>>> I propose we deprecate Geode’s proprietary UDP message privacy algorithm
>>>> based on the Diffie-Hellman key exchange protocol. This would deprecate:
>>>>
>>>> ConfigurationProperties.SECURITY_UDP_DHALGO
>>>>
>>>> String DistributionConfig.getSecurityUDPDHAlgo()
>>>>
>>>> void DistributionConfig.setSecurityUDPDHAlgo(String attValue)
>>>> DistributionConfig.SECURITY_UDP_DHALGO_NAME
>>>>
>>>> Additionally we’d have to upate documentation to reflect deprecation.
>>>>
>>>> From ConfigurationProperties.java:
>>>>
>>>>
>>>> Application can set this property to valid symmetric key algorithm, to
>>>> encrypt udp messages in Geode. Geode will generate symmetric key using
>>>> Diffie-Hellman key exchange algorithm between peers. That key further
>>> used
>>>> by specified algorithm to encrypt the udp messages.
>>>>
>>>> The property (and the feature) was added mid-2016. Unfortunately it was
>>> not
>>>> added as an “experimental” feature, so it cannot simply be removed.
>>>>
>>>> Incidentally, the corresponding property for client-server communication,
>>>> SECURITY_CLIENT_DHALGO, is already deprecated. It was deprecated in Geode
>>>> 1.5 in favor of SSL/TLS.
>>>>
>>>> I am proposing deprecating the feature because:
>>>>
>>>>
>>>> 1.
>>>>
>>>> The feature has not proven popular with users.
>>>> 2.
>>>>
>>>> At least one hard-to-reproduce bug exists in the implementation:
>>>> GEODE-6448 <https://issues.apache.org/jira/browse/GEODE-6448>. We’ve
>>>> burned a person-week trying to fix the problem (Bruce Schuchardt and
>>> me)
>>>> and it’s not clear how much more time it will take. If we decide to
>>>> deprecate the feature, fixing this problem would be de-prioritized
>>>> accordingly.
>>>> 3.
>>>>
>>>> If we decide, in the future, that UDP message security is required, it
>>>> would be better to implement a standard algorithm such as DTLS
>>>> <https://tools.ietf.org/html/rfc6347>:
>>>> 1.
>>>>
>>>> Our algorithm provides only message privacy whereas DTLS provides
>>>> privacy, tamper-resistance, and message forgery protection
>>>> 2.
>>>>
>>>> DTLS is a standard
>>>> 3.
>>>>
>>>> There is some support for DTLS in the JDK (JEP-219
>>>> <https://openjdk.java.net/jeps/219> delivered in JDK 9). It’s not a
>>>> complete implementation e.g. guaranteed delivery is a
>>> do-it-yourself kit.
>>>>
>>>> Actually implementing DTLS is out of scope for this proposal. Adding DTLS
>>>> would be a significant undertaking.
>>>>
>>>> So, how do you feel about me making a GEODE ticket to deprecate the
>>>> SECURITY_UDP_DHALGO configuration property?
>>>
Re: Let's Deprecate the SECURITY_UDP_DHALGO Configuration Property
Posted by Udo Kohlmeyer <uk...@pivotal.io>.
+1 to adding the deprecation. But I would prefer that we give users more
notice than 3 months.
maybe we deprecate it in 1.14
--Udo
On 2/28/20 1:00 PM, Ernest Burghardt wrote:
> +1
>
> seems reasonable to do this for 1.12 and be ahead of the game, @Owen would
> you please spawn that as a separate release 1.12 thread? thanks, eB
>
> On Fri, Feb 28, 2020 at 11:56 AM Owen Nichols <on...@pivotal.io> wrote:
>
>> +1
>>
>> We should have done this as soon as SSL/TLS was ready. Better late than
>> never!
>>
>> While we normally wait until a major release to remove deprecated stuff,
>> there is some precedent for removing insecure encryption algorithms sooner
>> (Java has done this even in patch releases). We should consider getting
>> the deprecation notice into 1.12 and removing in 1.13, rather than waiting
>> for 2.0.
>>
>>> On Feb 28, 2020, at 11:42 AM, Bill Burcham <bi...@gmail.com>
>> wrote:
>>> I propose we deprecate Geode’s proprietary UDP message privacy algorithm
>>> based on the Diffie-Hellman key exchange protocol. This would deprecate:
>>>
>>> ConfigurationProperties.SECURITY_UDP_DHALGO
>>>
>>> String DistributionConfig.getSecurityUDPDHAlgo()
>>>
>>> void DistributionConfig.setSecurityUDPDHAlgo(String attValue)
>>> DistributionConfig.SECURITY_UDP_DHALGO_NAME
>>>
>>> Additionally we’d have to upate documentation to reflect deprecation.
>>>
>>> From ConfigurationProperties.java:
>>>
>>>
>>> Application can set this property to valid symmetric key algorithm, to
>>> encrypt udp messages in Geode. Geode will generate symmetric key using
>>> Diffie-Hellman key exchange algorithm between peers. That key further
>> used
>>> by specified algorithm to encrypt the udp messages.
>>>
>>> The property (and the feature) was added mid-2016. Unfortunately it was
>> not
>>> added as an “experimental” feature, so it cannot simply be removed.
>>>
>>> Incidentally, the corresponding property for client-server communication,
>>> SECURITY_CLIENT_DHALGO, is already deprecated. It was deprecated in Geode
>>> 1.5 in favor of SSL/TLS.
>>>
>>> I am proposing deprecating the feature because:
>>>
>>>
>>> 1.
>>>
>>> The feature has not proven popular with users.
>>> 2.
>>>
>>> At least one hard-to-reproduce bug exists in the implementation:
>>> GEODE-6448 <https://issues.apache.org/jira/browse/GEODE-6448>. We’ve
>>> burned a person-week trying to fix the problem (Bruce Schuchardt and
>> me)
>>> and it’s not clear how much more time it will take. If we decide to
>>> deprecate the feature, fixing this problem would be de-prioritized
>>> accordingly.
>>> 3.
>>>
>>> If we decide, in the future, that UDP message security is required, it
>>> would be better to implement a standard algorithm such as DTLS
>>> <https://tools.ietf.org/html/rfc6347>:
>>> 1.
>>>
>>> Our algorithm provides only message privacy whereas DTLS provides
>>> privacy, tamper-resistance, and message forgery protection
>>> 2.
>>>
>>> DTLS is a standard
>>> 3.
>>>
>>> There is some support for DTLS in the JDK (JEP-219
>>> <https://openjdk.java.net/jeps/219> delivered in JDK 9). It’s not a
>>> complete implementation e.g. guaranteed delivery is a
>> do-it-yourself kit.
>>>
>>> Actually implementing DTLS is out of scope for this proposal. Adding DTLS
>>> would be a significant undertaking.
>>>
>>> So, how do you feel about me making a GEODE ticket to deprecate the
>>> SECURITY_UDP_DHALGO configuration property?
>>
Re: Let's Deprecate the SECURITY_UDP_DHALGO Configuration Property
Posted by Ernest Burghardt <eb...@pivotal.io>.
+1
seems reasonable to do this for 1.12 and be ahead of the game, @Owen would
you please spawn that as a separate release 1.12 thread? thanks, eB
On Fri, Feb 28, 2020 at 11:56 AM Owen Nichols <on...@pivotal.io> wrote:
> +1
>
> We should have done this as soon as SSL/TLS was ready. Better late than
> never!
>
> While we normally wait until a major release to remove deprecated stuff,
> there is some precedent for removing insecure encryption algorithms sooner
> (Java has done this even in patch releases). We should consider getting
> the deprecation notice into 1.12 and removing in 1.13, rather than waiting
> for 2.0.
>
> > On Feb 28, 2020, at 11:42 AM, Bill Burcham <bi...@gmail.com>
> wrote:
> >
> > I propose we deprecate Geode’s proprietary UDP message privacy algorithm
> > based on the Diffie-Hellman key exchange protocol. This would deprecate:
> >
> > ConfigurationProperties.SECURITY_UDP_DHALGO
> >
> > String DistributionConfig.getSecurityUDPDHAlgo()
> >
> > void DistributionConfig.setSecurityUDPDHAlgo(String attValue)
> > DistributionConfig.SECURITY_UDP_DHALGO_NAME
> >
> > Additionally we’d have to upate documentation to reflect deprecation.
> >
> > From ConfigurationProperties.java:
> >
> >
> > Application can set this property to valid symmetric key algorithm, to
> > encrypt udp messages in Geode. Geode will generate symmetric key using
> > Diffie-Hellman key exchange algorithm between peers. That key further
> used
> > by specified algorithm to encrypt the udp messages.
> >
> > The property (and the feature) was added mid-2016. Unfortunately it was
> not
> > added as an “experimental” feature, so it cannot simply be removed.
> >
> > Incidentally, the corresponding property for client-server communication,
> > SECURITY_CLIENT_DHALGO, is already deprecated. It was deprecated in Geode
> > 1.5 in favor of SSL/TLS.
> >
> > I am proposing deprecating the feature because:
> >
> >
> > 1.
> >
> > The feature has not proven popular with users.
> > 2.
> >
> > At least one hard-to-reproduce bug exists in the implementation:
> > GEODE-6448 <https://issues.apache.org/jira/browse/GEODE-6448>. We’ve
> > burned a person-week trying to fix the problem (Bruce Schuchardt and
> me)
> > and it’s not clear how much more time it will take. If we decide to
> > deprecate the feature, fixing this problem would be de-prioritized
> > accordingly.
> > 3.
> >
> > If we decide, in the future, that UDP message security is required, it
> > would be better to implement a standard algorithm such as DTLS
> > <https://tools.ietf.org/html/rfc6347>:
> > 1.
> >
> > Our algorithm provides only message privacy whereas DTLS provides
> > privacy, tamper-resistance, and message forgery protection
> > 2.
> >
> > DTLS is a standard
> > 3.
> >
> > There is some support for DTLS in the JDK (JEP-219
> > <https://openjdk.java.net/jeps/219> delivered in JDK 9). It’s not a
> > complete implementation e.g. guaranteed delivery is a
> do-it-yourself kit.
> >
> >
> > Actually implementing DTLS is out of scope for this proposal. Adding DTLS
> > would be a significant undertaking.
> >
> > So, how do you feel about me making a GEODE ticket to deprecate the
> > SECURITY_UDP_DHALGO configuration property?
>
>
Re: Let's Deprecate the SECURITY_UDP_DHALGO Configuration Property
Posted by Owen Nichols <on...@pivotal.io>.
+1
We should have done this as soon as SSL/TLS was ready. Better late than never!
While we normally wait until a major release to remove deprecated stuff, there is some precedent for removing insecure encryption algorithms sooner (Java has done this even in patch releases). We should consider getting the deprecation notice into 1.12 and removing in 1.13, rather than waiting for 2.0.
> On Feb 28, 2020, at 11:42 AM, Bill Burcham <bi...@gmail.com> wrote:
>
> I propose we deprecate Geode’s proprietary UDP message privacy algorithm
> based on the Diffie-Hellman key exchange protocol. This would deprecate:
>
> ConfigurationProperties.SECURITY_UDP_DHALGO
>
> String DistributionConfig.getSecurityUDPDHAlgo()
>
> void DistributionConfig.setSecurityUDPDHAlgo(String attValue)
> DistributionConfig.SECURITY_UDP_DHALGO_NAME
>
> Additionally we’d have to upate documentation to reflect deprecation.
>
> From ConfigurationProperties.java:
>
>
> Application can set this property to valid symmetric key algorithm, to
> encrypt udp messages in Geode. Geode will generate symmetric key using
> Diffie-Hellman key exchange algorithm between peers. That key further used
> by specified algorithm to encrypt the udp messages.
>
> The property (and the feature) was added mid-2016. Unfortunately it was not
> added as an “experimental” feature, so it cannot simply be removed.
>
> Incidentally, the corresponding property for client-server communication,
> SECURITY_CLIENT_DHALGO, is already deprecated. It was deprecated in Geode
> 1.5 in favor of SSL/TLS.
>
> I am proposing deprecating the feature because:
>
>
> 1.
>
> The feature has not proven popular with users.
> 2.
>
> At least one hard-to-reproduce bug exists in the implementation:
> GEODE-6448 <https://issues.apache.org/jira/browse/GEODE-6448>. We’ve
> burned a person-week trying to fix the problem (Bruce Schuchardt and me)
> and it’s not clear how much more time it will take. If we decide to
> deprecate the feature, fixing this problem would be de-prioritized
> accordingly.
> 3.
>
> If we decide, in the future, that UDP message security is required, it
> would be better to implement a standard algorithm such as DTLS
> <https://tools.ietf.org/html/rfc6347>:
> 1.
>
> Our algorithm provides only message privacy whereas DTLS provides
> privacy, tamper-resistance, and message forgery protection
> 2.
>
> DTLS is a standard
> 3.
>
> There is some support for DTLS in the JDK (JEP-219
> <https://openjdk.java.net/jeps/219> delivered in JDK 9). It’s not a
> complete implementation e.g. guaranteed delivery is a do-it-yourself kit.
>
>
> Actually implementing DTLS is out of scope for this proposal. Adding DTLS
> would be a significant undertaking.
>
> So, how do you feel about me making a GEODE ticket to deprecate the
> SECURITY_UDP_DHALGO configuration property?
Re: Let's Deprecate the SECURITY_UDP_DHALGO Configuration Property
Posted by Bruce Schuchardt <br...@vmware.com.INVALID>.
+1
On 2/28/20, 11:43 AM, "Bill Burcham" <bi...@gmail.com> wrote:
I propose we deprecate Geode’s proprietary UDP message privacy algorithm
based on the Diffie-Hellman key exchange protocol. This would deprecate:
ConfigurationProperties.SECURITY_UDP_DHALGO
String DistributionConfig.getSecurityUDPDHAlgo()
void DistributionConfig.setSecurityUDPDHAlgo(String attValue)
DistributionConfig.SECURITY_UDP_DHALGO_NAME
Additionally we’d have to upate documentation to reflect deprecation.
From ConfigurationProperties.java:
Application can set this property to valid symmetric key algorithm, to
encrypt udp messages in Geode. Geode will generate symmetric key using
Diffie-Hellman key exchange algorithm between peers. That key further used
by specified algorithm to encrypt the udp messages.
The property (and the feature) was added mid-2016. Unfortunately it was not
added as an “experimental” feature, so it cannot simply be removed.
Incidentally, the corresponding property for client-server communication,
SECURITY_CLIENT_DHALGO, is already deprecated. It was deprecated in Geode
1.5 in favor of SSL/TLS.
I am proposing deprecating the feature because:
1.
The feature has not proven popular with users.
2.
At least one hard-to-reproduce bug exists in the implementation:
GEODE-6448 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-6448&data=02%7C01%7Cbruces%40vmware.com%7Ccd3777c845544f7d0ea008d7bc866b3f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637185157829173567&sdata=rHYsNtYHz1cyPH5RtT1neqARzIGVqP7oRJ0RJ1llXLs%3D&reserved=0>. We’ve
burned a person-week trying to fix the problem (Bruce Schuchardt and me)
and it’s not clear how much more time it will take. If we decide to
deprecate the feature, fixing this problem would be de-prioritized
accordingly.
3.
If we decide, in the future, that UDP message security is required, it
would be better to implement a standard algorithm such as DTLS
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc6347&data=02%7C01%7Cbruces%40vmware.com%7Ccd3777c845544f7d0ea008d7bc866b3f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637185157829173567&sdata=UiKnGMT%2FgomuKMf%2FvkBhPpukUGHs42laFZ%2FDtFedoRo%3D&reserved=0>:
1.
Our algorithm provides only message privacy whereas DTLS provides
privacy, tamper-resistance, and message forgery protection
2.
DTLS is a standard
3.
There is some support for DTLS in the JDK (JEP-219
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.java.net%2Fjeps%2F219&data=02%7C01%7Cbruces%40vmware.com%7Ccd3777c845544f7d0ea008d7bc866b3f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637185157829173567&sdata=WaAYo1dyMEdm%2BvXM5kbTVwiL5ryIEXvx0qadMaPW1T8%3D&reserved=0> delivered in JDK 9). It’s not a
complete implementation e.g. guaranteed delivery is a do-it-yourself kit.
Actually implementing DTLS is out of scope for this proposal. Adding DTLS
would be a significant undertaking.
So, how do you feel about me making a GEODE ticket to deprecate the
SECURITY_UDP_DHALGO configuration property?
Re: Let's Deprecate the SECURITY_UDP_DHALGO Configuration Property
Posted by Kirk Lund <kl...@apache.org>.
+1 to deprecating and removing SECURITY_UDP_DHALGO. The current
implementation is a non-thread-safe hack that would require extensive work
to "fix". It fails EVERY time we run mass test run. I'd prefer to see us
embrace DTLS as a standard.
On Fri, Feb 28, 2020 at 11:43 AM Bill Burcham <bi...@gmail.com>
wrote:
> I propose we deprecate Geode’s proprietary UDP message privacy algorithm
> based on the Diffie-Hellman key exchange protocol. This would deprecate:
>
> ConfigurationProperties.SECURITY_UDP_DHALGO
>
> String DistributionConfig.getSecurityUDPDHAlgo()
>
> void DistributionConfig.setSecurityUDPDHAlgo(String attValue)
> DistributionConfig.SECURITY_UDP_DHALGO_NAME
>
> Additionally we’d have to upate documentation to reflect deprecation.
>
> From ConfigurationProperties.java:
>
>
> Application can set this property to valid symmetric key algorithm, to
> encrypt udp messages in Geode. Geode will generate symmetric key using
> Diffie-Hellman key exchange algorithm between peers. That key further used
> by specified algorithm to encrypt the udp messages.
>
> The property (and the feature) was added mid-2016. Unfortunately it was not
> added as an “experimental” feature, so it cannot simply be removed.
>
> Incidentally, the corresponding property for client-server communication,
> SECURITY_CLIENT_DHALGO, is already deprecated. It was deprecated in Geode
> 1.5 in favor of SSL/TLS.
>
> I am proposing deprecating the feature because:
>
>
> 1.
>
> The feature has not proven popular with users.
> 2.
>
> At least one hard-to-reproduce bug exists in the implementation:
> GEODE-6448 <https://issues.apache.org/jira/browse/GEODE-6448>. We’ve
> burned a person-week trying to fix the problem (Bruce Schuchardt and me)
> and it’s not clear how much more time it will take. If we decide to
> deprecate the feature, fixing this problem would be de-prioritized
> accordingly.
> 3.
>
> If we decide, in the future, that UDP message security is required, it
> would be better to implement a standard algorithm such as DTLS
> <https://tools.ietf.org/html/rfc6347>:
> 1.
>
> Our algorithm provides only message privacy whereas DTLS provides
> privacy, tamper-resistance, and message forgery protection
> 2.
>
> DTLS is a standard
> 3.
>
> There is some support for DTLS in the JDK (JEP-219
> <https://openjdk.java.net/jeps/219> delivered in JDK 9). It’s not a
> complete implementation e.g. guaranteed delivery is a do-it-yourself
> kit.
>
>
> Actually implementing DTLS is out of scope for this proposal. Adding DTLS
> would be a significant undertaking.
>
> So, how do you feel about me making a GEODE ticket to deprecate the
> SECURITY_UDP_DHALGO configuration property?
>