Re: [TLS] Contemplated major revision to draft-ietf-negotiated-ff-dhe

[Ilari Liusvaara <[e-mail]>]

On Fri, Sep 19, 2014 at 03:52:31PM -0400, Daniel Kahn Gillmor wrote:
> 
>    The idea is to have the draft drop the proposed FF-DHE TLS extension
>    entirely and instead redefine "Supported Elliptic curves" (TLS
>    extension 10) [0] to be a "Supported named groups" extension.  Then
>    we would allocate some of the currently unallocated codepoints in the
>    NamedCurve IANA registry [1] to the proposed FF-DHE groups.
> 
> == Advantages ==
> 
> The main goal of this change is to simplify the TLS 1.3 handshake while
> allowing clients to send a 1.2+1.3 compatible first flight that includes
> FF DHE without excessive duplication.

Couple problems:
- Implementations may not support same curves for ECDH and ECDSA, and SEC
  negotiates both.
- It would be clearer if TLS 1.3 worked in terms of DH functions instead
  of DH groups (avoids problems with encodings for one, which are made
  more severe by inability to negotiate).

Just check some drafts trying to fit Curve25519 into TLS. Those are quite
hacky. Making DH function out of it would be trivial (since it already
is DHF).

DH Groups can be turned into DHFs by specifying encoding rules (which
have to be specified anyway).

Also, there are things even more exotic than Curve25519 & co. Like what
is called "Kummer" in eBATS.

> For aware servers, if they select a DHE key exchange they should send an
> SKE as indicated in the current draft, with the server's DHParams
> modified appropriately.  (possibly, Alfredo's suggestion of sending an
> entirely different handshake message instead of SKE in this case offers
> a clearer indication to the client that the server has selected a named
> group).

SKE is quite different in 1.2 and 1.3:

In 1.2, it also carries server signature. This does not specify the group
used, which leads into a security problem since groups can be confused.

In 1.3 the server signature is elsewhere (it has to be because of certificate
encryption) which also avoids the group confusion problem (and some
annoyances at analyzing security of key exchange).


If server's choice of DHG/DHF is specified in ServerHello or SKE is also
dependent on how "missed guess" is handled. There are two basic ways:
1) Restart. DHG/DHF has to be in SH. Potential for downgrade attacks?
2) Remedial CKE. The DHG/DHF can be in either SH or SKE.



-Ilari