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

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

Hi TLS folks--

I'm considering a radical syntactic change to the negotiated-ff-dhe
draft (though it changes the semantics very little if at all) for the
purposes of aligning 1.3 handshake with pre-1.3 handshakes.  Feedback
about this idea would be appreciated.


   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.

TLS 1.2+1.3 handshakes will be able to reference a single registry for
their preferred groups and handle them in parallel, without an extra
extension.  We also avoid introducing new TLS extensions.  Clients
would be able to send extension 10 without needing to have implemented
EC.


== Further Considerations ==

So, for a TLS 1.2 client that wants to support named FF-DHE groups, it
would just send TLS extension 10 with only FF-DHE codepoints.  It would
include DHE ciphersuites, but need not include any ciphersuites with
ECDHE key exchange.

If a TLS 1.2 client wants to include ciphersuites with ECDHE as well, it
can do so, but can also indicate FF-DHE codepoints in the same TLS
extension that it indicates the available curves.

Servers responding to such a client will fall into two categories: those
aware of the FF-DHE entries in named-curves, and those that are not.

for unaware servers, they should ignore these entries and carry on with
a normal response.

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


== Codepoint Requests ==

The NamedCurve registry is 16 bits, which is *huge* considering the
pressure we've given to the CFRG to limit the number of proposed curves.

This proposal suggests carving out a small space of that registry for
finite field groups.  For simplicity's sake, i imagine something like
"if the high byte is 0x01, it's FF-DHE" (the draft currently only
allocates 1 byte anyway).  But i'd also be OK with just allocating some
specific codepoints and not making any block designation, if folks think
that would make more sense.


== Feedback Please! ==

Please speak up if you find this change terrible for some reason, or if
you've already implemented the proposed draft and think that backing it
out would be misery.  I don't think this proposal changes the semantics
of the draft at all, and i think it would help the 1.3 handshake to have
this established.

If i hear no shouts of horror, i hope to get a revision of
negotiated-ff-dhe published next week with these changes.

I'm likely to need some help in navigating the IANA procedures for a
change like this which isn't exactly a straightforward codepoint
request, so if anyone has suggestions or experience with that, i'd
appreciate pointers.


All the best,

        --dkg


[0] https://tools.ietf.org/html/rfc4492#section-5.1.1
[1] https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8