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 mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
