On Fri 2018-12-07 07:14:17 +0000, Peter Gutmann wrote: > I appreciate that people feel strongly about this, and I support the idea of > non-ephemeral DHE detection in principal [0] (along with many, many other > measures to strengthen TLS), but this draft reads a lot like the IETF blowing > raspberries at ETSI.
hm, it's true that i'm not happy with ETSI's decision-making process here, but my goal with the draft is to provide a measure of defense for TLS clients on the public Internet who might accidentally/unknowingly come into contact with some errant eTLS server implementation that has escaped the enterprise data center, and not realize it. If you want to suggest ways to reduce the raspberry-blowing-ness of it, i'm all ears. My initial (unpublished) copy of the draft didn't contain the "Problems with static DH" section at all, it was just a quick set of guidance on how to mitigate the risks introduced by this potential ecosystem change. I added the "Problems" section because i wanted to document the very real concerns; it's not a raspberry-blowing doc for the sake of rasberries. > but getting into an arms race you know you can't win seems like, well, > workgroup posturing. Another way that someone who wants to leak secrets could leak them would be to use a bad FFDHE group and small subgroup during key exchange (indeed, this can happen by accident in some cases), or by enabling and encouraging the use of export ciphersuites. But we discourage people from doing bad FFDHE at a protocol level in TLS 1.2 (where arbitrary groups are allowed) by encouraging peers to reject handshakes that are not in the right-sized subgroup. If you can detect that the peer is misbehaving, shouldn't you act on it? Otherwise, what's the point of detection? > [0] "In principal" because there's a fair bit of SCADA gear that does this > because it doesn't have the CPU power to generate new DHE values, as I > found out when I turned on non-DHE checking some years ago. Is this SCADA gear running TLS 1.3? is it clients and servers both, or just one or the other? When was this scan done? i'd love to see more documentation about this practice. --dkg
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls