On Fri, Aug 19, 2016 at 2:35 PM Geoffrey Keating <geo...@geoffk.org> wrote:
> Peter Gutmann <pgut...@cs.auckland.ac.nz> 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
