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

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 19 Sep 2014 15:52:31 -0400

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 20 Sep 2014 00:09:59 +0300

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

> a clearer indication to the client that the server has selected a named

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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 19 Sep 2014 15:05:36 -0700

> == Advantages ==

Great.  This is much nicer as a rule.

I think that the issues Ilari points are entirely orthogonal to this
proposal, those are largely existing problems with the existing stuff.
I do have one suggestion below that might help alleviate concerns like
those though.

> finite field groups.

I would rather you add a parameter to the registry so that entities
that understand the code point can identify if the group is FF or EC.
It would be informative only, scoping the registration appropriately.
If further division is required, then more fields can be added.  For
instance, if Ilari's idea to separate ECDH and ECDSA use is something
we decide to do, then the "type" field can be set to ECDH, ECDSA or
ECDH+ECDSA (or FF).  I'm not sure that that helps on the ServerHello
end of things though.

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 20 Sep 2014 12:20:03 +0300

> Great.  This is much nicer as a rule.

Yeah, I think this proposal sounds good.

Process question: Does this need to update 4492 (it repurposes extensions
defined there)?

> I do have one suggestion below that might help alleviate concerns like

I actually figured out solutions to those issues, without impacting this
specification (and I consider those less radical than this spec).

> It would be informative only, scoping the registration appropriately.

Yeah, I think it should be done that way.

> I'm not sure that that helps on the ServerHello end of things though.

Talking about TLS 1.0-1.2 or 1.3?

If 1.0-1.2, I don't see how ServerHello is involved (you don't have to
signal the DH group used in elliptic_curves). 

If 1.3, where the group used is signaled anyway? I can't find it it
in either SH or SKE.

Regarding server key misinterpretation problems (only affects TLS
1.0-1.2), the notation differences between 1.2 and 4492 make
seeing what is actually signed hard. So I can't say about
possiblity of misinterpretting SKE.

Also, regarding TLS libs not accepting <9 bit DHE, I have seen certain
infamous TLS library accept some ridiculously short DHE prime (I
think it was 16 bits or something like that)... But such problems
should be fixed.

-Ilari