Re: [TLS] RFC 7919 on Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)

[David Benjamin <[e-mail]>]

On Fri, Aug 19, 2016 at 2:35 PM Geoffrey Keating <[e-mail]> wrote:

> Peter Gutmann <[e-mail]> writes:
>
> > The problem is that 7919 doesn't say "I want to do DHE, if possible
> > with these parameters", it says "I will only accept DHE if you use
> > these parameters, otherwise you cannot use DHE but must drop back to
> > RSA".  Talk about cutting off your nose to spite your face, you'd
> > have to have rocks in your head to want to break your implementation
> > like that.
>
> Actually, my problem with the RFC is the reverse.  If you have an
> implementation which won't accept certain DH groups, and those are
> extremely common in legacy software (1024-bit, for example), there's
> no way to stop those legacy implementations ignoring the extension and
> choosing DH, which you will then have to reject, doubling connection
> establishment time.
>
> So Apple's client still has DH off.
>
> However I don't see a helpful solution to this; the obvious thing is
> to have a new ciphersuite, but it's hard to see how that would be
> worth the effort if it requires new implementations and ECDHE is
> already standardised and already implemented in many places.
>

TLS 1.3 will resolve this with the new cipher suite negotiation, but I
agree this makes the specification basically undeployable with TLS 1.2.
This issue also got brought up here:
https://www.ietf.org/mail-archive/web/tls/current/msg18697.html

Barring unforeseen problems, Chrome will also lose DH in the next release.
We certainly could not deploy this without the separate cipher suite
numbers. But I can't imagine Chrome deploying it with the separate cipher
suite numbers either for the same reason as Geoffrey. It does not seem
worth bothering when ECDHE is already widely deployed.

David