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

Reply via email to