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?
