Re: [TLS] draft-dkg-tls-reject-static-dh

[Daniel Kahn Gillmor <[e-mail]>]

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