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?
