Re: [TLS] TLS 1.3 draft-07 sneak peek

["Dang, Quynh" <[e-mail]>]

Hi Eric,

Since the key derivation method is the HKDF method, I think the current PRF (in TLS 1.2) should be removed/changed. The key-expansion step in the HKDF should be used to generate keying materials.

For resumptions, will you re-run the resumption master secrets through the extraction step again or just run them through the key expansion step? I don't think the extraction step is necessary here.

Quynh.

________________________________
From: TLS <[e-mail]> on behalf of Eric Rescorla <[e-mail]>
Sent: Tuesday, June 30, 2015 6:23 PM
To: [e-mail]
Subject: [TLS] TLS 1.3 draft-07 sneak peek

Folks,

Yesterday, I posted the -06 draft which snapshots the consensus changes
made since -05, specifically:

- Prohibit RC4 negotiation for backwards compatibility.
- Freeze & deprecate record layer version field.
- Update format of signatures with context.
- Remove explicit IV.


In the background, I've also been working 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'm planning to merge this into
master soon and submit it as draft-07 next week, but I wanted to
e-mail the list and give people a chance to comment before I do
that. I've provided a summary of the major changes and open issues
below. Remember, this is a WIP 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). 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.


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. I plan to rewrite the Handshake Protocol Overview (S 6.2)
to be clearer. I hope to do this before submitting -07.

5. 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 still a WIP, so no doubt contains
a number of errors, potentially serious ones. 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.