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

[Brian Smith <[e-mail]>]

On Wed, Dec 10, 2014 at 12:27 PM, Daniel Kahn Gillmor
<[e-mail]> wrote:
> On 12/10/2014 01:33 AM, Brian Smith wrote:
>> * 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,
>
> There are no FFDHE-specific extensions in the draft, just a reuse of
> NamedCurves on the client side to specify FFDHE groups.

Understood. Sorry for being lazy with the terminology there.

>> 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.
>
> If there is a change in the way that you think the signature should be
> processed in draft-ietf-tls-negotiated-ff-dhe, please suggest a concrete
> change.

I do not think a change to draft-ietf-tls-negotiated-ff-dhe is needed.

>> 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.
>
> I'm not sure i reach the same conclusion.  consider it from both sides:
>
>  * full handshake, client sends first
>
>    In this situation, the client sent the server a list of preferred
> FFDHE groups.  the server either responded with one of them, or did not
> respond with one of them.  If the server responded with one of them, and
> it was signed by the server's validated public key, why should this
> preclude the use of FalseStart by the client?  The server replied with a
> value from an acceptable group, and the message (including client and
> server randoms for freshness) was signed by the server.  Why should a
> client refuse to send traffic early in this case?

The MitM may have tampered with or removed the FFDHE groups from the
extension in the ClientHello, misleading the server into thinking the
client's capabilities are weaker than they actually are, and thus
causing the server to choose weaker DHE parameters. The tampering will
be detected by the server when it validates the Client's Finished
message, but by that time the client will have already sent data
encrypted with keys derived from the weak DHE key material.

> Perhaps the false start draft should say that a client shouldn't do
> false start for a server that offers FFDHE but does not send an
> acceptable named group.

I agree that the client could maintain a whitelist of
false-start-acceptable FFDHE groups, which should be a subset of the
FFDHE groups listed in its supported curves extension. However,
wording to that effect, and wording about how to compare the strength
of ECDHE groups to FFDHE groups, should be included in the draft if
FFDHE support is going to continue to be recommended. IMO, FFDHE is
basically obsolete now, so it isn't worth the effort to do this.
However, I understand that others might disagree.

Cheers,
Brian