[TLS] TLS 1.3 draft-07

[Eric Rescorla <[e-mail]>]

As you probably expected from
(https://www.ietf.org/mail-archive/web/tls/current/msg16881.html)
I've just posted draft-07.

This version is the result of a bunch of work in the the background,
with Hugo, Hoeteck, Karthik, and others to develop a new draft using
semi-ephemeral DH based on Hugo's ideas as discussed in Dallas.  I've
provided a summary of the major changes and open issues below and I
expect to go over them in detail in Prague. Remember, this is a WIP with
a lot of changes, so if you see something wrong, don't panic, but do let me
know.


CHANGES
1. Move ClientKeyShare into an extension so that the ClientHello
   is the only message in the client's first flight. This removes
   a bunch of ugliness around the "early_data" extension which
   could encapsulate handshake and application data.

2. Added a mechanism for the server to indicate a known (EC)DHE
   key/configuration which the client can then use in subsequent
   handshakes (via the known_configuration extension). The net
   effect here is that the client and server can skip over the
   signature in subsequent handshakes, which provides benefit
   when signatures are much slower than key exchange, as with
   RSA; it also enables 0-RTT.

3. Added support for 0-RTT data, both with and without
   client authentication.

4. Removed most of the support for resumption in favor of
   a mechanism proposed by Karthik where you just establish
   a PSK in connection N which you then use to key a PSK
   cipher suite in connection N+1.

All of these keying mechanisms use a unified key schedule based on two
keys the "Ephemeral Secret" (ES) and the "Static Secret"
(SS). Depending on the exact handshake type, these may be equal, but
the logic is the same regardless. In the process, I also converted
the key schedule to use HKDF (per WG consensus).


OPEN ISSUES
There are still a number of known open issues to discuss:

1. The present known_configuration mechanism allows the client to
resurrect the handshake parameters (though not the keys) which were
negotiated in a previous handshake, but this is done implicitly, i.e.,
the server provides a label and the client returns it on the next
connection. This has the advantage of keeping things short but the
disadvantage the it means that you can't have a static configuration
ID for everyone (instead, the server has to somehow embed the
properties in the configuration ID). I'm not that satisfied with the
present design and there are (at least) three potential alternative
designs:

   (a) Have the client indicate in his first flight "these are the
       parameters I expect you to negotiate", along with the
       configuration identifier, based on what the server
       negotiated the previous time. [Optionally, the server
       can run the same negotiation locally and abort on mismatch.]

   (b) As in (a) but with no indication of the expected parameters,
       just the configuration ID, and the client just preemptively
       uses the parameters from the last time and if the negotiation
       ends up differently, all the data is undecryptable
       (ugh) and you somehow fall back.

   (c) Have the server provide a preference list in his
       ServerConfiguration (this can be the same as in the
       ClientHello) and have the client do the negotiation based on
       that rather than the server (as in QUIC). This is a little odd
       in that it means that sometimes the server selects the
       parameters and sometimes the client does, but it's not that
       hard to make this code symmetrical.

As I think this through, I am leaning towards (a) but other people's
opinions on this topic would be welcome. Expect a mesage about this
shortly.


2. Should we require that PSK cipher suites where the PSK is used for
resumption use compatible ciphers? This is the way it was in TLS 1.2
and below for resumption and tickets, but once you have a PSK, that's
not really necessary [0]. So, for instance, if you had the following
cipher list order:

    ECDHE + AES-GCM
    ECDHE + ChaCha/Poly
    PSK + ChaCha/Poly
    PSK + AES-GCM

You could potentially negotiate one connection with GCM, use it
to establish a shared key, and then reconnect with ChaCha/Poly.
This seems like it probably should be something we avoid, though
I'm not sure we have a concrete reason why, and it means a
weird special case for PSK. Note that this issue might be
ameliorated some (though not completely) with a la carte negotiation.


3. I don't currently have PSK/Resumption + 0-RTT working, because you
need a way to indicate the expected parameters (see point #1 above).

4. Security Considerations is badly out of date, so I plan to
rewrite that soon, but probably not before Prague. I also intend
to do a pretty substantial editorial cleanup pass and potentially
some restructuring after Prague.


As indicated above, this is a pretty major revision, so is still kind
of a hard hat area and no doubt contains a number of errors,
potentially serious ones (as well as a big pile of TODOs).
Comments and PRs welcome.

Thanks,
-Ekr


[0] With the exception of cryptographic concerns about the use
of the same IKM with different hash functions for HKDF, but this
is a problem that applies to any use of PSK, not just this one.