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

[Daniel Kahn Gillmor <[e-mail]>]

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.

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

 * 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