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? >
