+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 <amurm...@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 <u...@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 <ukohlme...@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 <ukohlme...@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 <ukohlme...@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 <onich...@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.burc...@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? >>
