[TLS] False Start, DHE key exchange, and the Negotiated FF-DHE extension

[Brian Smith <[e-mail]>]

* The vast majority of servers that pick DHE key exchange, in Firefox
at least, are using 1024-bit *or smaller* DHE keys, and/or keys with
other problems.

* It may be the case that the server is configured with good ECDHE
parameters and DHE parameters that aren't as strong as the ECDHE
parameters. In fact, most servers that support both ECDHE and DHE key
exchange seem to be configured like this: P-256 for ECDHE, and
1024-bit keys for DHE. (Note that the key size may not be the only
issue with the DHE parameters, and that the possible problems with DH
parameters other than key size are difficult and/or very expensive to
check.) An attacker can modify the ClientHello to trick such a server
into choosing its weak DHE parameters instead of its strong ECDHE
parameters.

* The Negotiated FF-DHE draft mechanism is specified in such a way
that the server's signature on DHParams does not cover the client or
server FF-DHE extensions, because the definition of DHParams was not
modified to cover them. This is unfortunate, because it means that
these parameters, and thus the entire DHE exchange, cannot be fully
validated until the peer's Finished message is validated. In
particular, this means that the FF-DHE mechanism, as currently
designed, is not useful for enhancing the security of False Start
handshakes that use DHE key exchange.

* Firefox and Chrome (IIUC) are both removing support for DHE_DSS key
exchange, due to non-use by servers and/or too-small key DSS key sizes
(almost always 1024 bits). Obviously, there are other implementations
to consider, but I think the reasoning behind the Firefox and Chrome
decisions likely applies to most/all other implementations that would
do False Start.

Because of the above issues, the False Start draft should be changed
to remove DHE_RSA and DHE_DSS from the list of recommended key
exchange algorithms, leaving only ECDHE_RSA and ECDHE_ECDSA in the
list.

Cheers,
Brian