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

From: Brian Smith <[email-masked]>
Date: Tue, 9 Dec 2014 22:33:50 -0800

* 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

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 10 Dec 2014 15:27:29 -0500

On 12/10/2014 01:33 AM, Brian Smith wrote:
> 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.

> because the definition of DHParams was not
> 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 considered making a new Handshake message that differed from
ServerKeyExchange (but performed the same function) as the server's
response when selecting an offered FFDHE named group.  I found it
difficult to draft it in such a way that the mechanism would be
straightforward for implementers to add, but it's possible that (a) i
missed some obvious way to differentiate between a signed DHParams
object and one of these new objects, or (b) i was being too conservative
about what implementers would find acceptable.

(btw, if TLS was already following the excellent suggestion for always
using a string-prefix for signing anything, then distinguishing between
types of signed dh params would be a much easier call)

> In particular, this means that the FF-DHE mechanism, as currently

I'm not sure i reach the same conclusion.  consider it from both sides:

 * abbreviated handshake, server sends first

   i fail to see the risk here -- in the abbreviated handshake, the
client has identified itself by a TLS session ID or ticket, and is
resuming the existing session, so no key exchange is necessary.  use of
an FFDHE ciphersuite (or not) isn't relevant to this case.

 * 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?

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.

	--dkg

---

From: Brian Smith <[email-masked]>
Date: Mon, 15 Dec 2014 21:45:13 -0800

> NamedCurves on the client side to specify FFDHE groups.

Understood. Sorry for being lazy with the terminology there.

> processed in draft-ietf-tls-negotiated-ff-dhe, please suggest a concrete

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

> 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.

> false start for a server that offers FFDHE but does not send an

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

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 19 Dec 2014 13:19:12 -0500

> However, I understand that others might disagree.

I've modified the ffdhe draft (as of -05) to include this guidance.

https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-05

	--dkg

---

From: Brian Smith <[email-masked]>
Date: Tue, 23 Dec 2014 13:24:17 -0800

> https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-05

This looks good. However, I think this text actually belongs in
draft-bmoeller-tls-falsestart, not draft-ietf-tls-negotiated-ff-dhe,
because (a) it applies even when the negotiated ff-dhe mechanism isn't
being used, (b) there are other tamperings besides ff-dhe that can
cause a downgrade in DHE strength, and (c) I think it is best to keep
all the false start stuff together when practical.

I think you can drop "and MUST offer at least one of these in the
initial handshake if they contemplate using the False Start protocol
modification." What the client actually offers doesn't matter as far
as False Start security is concerned; the only thing that matters is
what the server receives.

I think implementers will need more help in determining what is
"cryptographically strong," such as a suggested minimum key sizes and
suggested countermeasures against exploits targetting servers
misconfigured in a way that would permit small subgroup attacks or
other weak keys. For example, the recommendation could be to only do
false start when the server uses parameters in the FF-DHE registry,
which addresses both small keys and small subgroup attacks.

I think that some mention of the attacker controlling the choice of
ECDHE vs FF-DHE is also worth mentioning.

Cheers,
Brian