Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt

[Henrick Hellström <[e-mail]>]

On 2014-10-26 08:09, Nikos Mavrogiannopoulos wrote:
> To be honest I don't see that to be a lot more complex, and the complexity
> on the same level as supporting ECDH with named groups and arbitrary groups,
> which was deemed reasonable for ECDH. Consistency (with ECDH) is also another
> reason to keep the code paths separated.

No, ECDHE is different, because you can't implement RFC 4492 (EC cipher 
suites) fully, unless your implementation supports the hello extensions 
and curve negotiation mechanism, and there exists clients that don't 
support arbitrary explicit curves. In the case of DHE, most clients will 
probably only support explicit groups and not support the extension and 
named groups at all, for several years ahead.

Consequently, a server that e.g. only implements secp256r1 encoded as a 
named curve, would stand a fair chance of being interoperable, if it 
simply refuses to negotiate ECDHE cipher suites unless the client sends 
a supported curve extension with this one included. A server that only 
wants to negotiate the FFDHE 3072 bit group could easily encode it as an 
arbitrary group if the client doesn't send the extension (which would 
still happen most of the time), but if the client *does* send the 
extension, then, under the current draft-02, the server would have to 
propagate this information to the server key exchange encoder somehow 
(be it with maps, switches or if-clauses).

> Note also, that the current approach will simplify a lot an implementation that
> doesn't want to keep the old DHE key exchange with arbitrary groups (and unlike
> the other key exchanges in TLS, DHE was the most problematic compatibility-wise so
> I guess many small implementations would be more than happy to drop it).

I don't know about compatibility issues, but rather see a security issue 
that SSL 3.0 up to TLS 1.2 didn't explicitly require the DHE parameters 
to have a bit size greater than or equal to the certificate public key. 
I don't know how common it is for clients that offer DHE cipher suites 
to be able to use the server certificate key for signature verification, 
but unable to compute a DHE handshake using integers of a comparable 
size. I doesn't seem reasonable to expect this to be a problem of such 
magnitude, that the standards should keep an acceptance for low(er) 
security (than necessary) in order to keep interoperability with such 
clients.