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

[Eric Rescorla <[e-mail]>]

I see I forgot to provide a link. Here:

https://github.com/ekr/tls13-spec/tree/WIP_draft_07

On Tue, Jun 30, 2015 at 3:23 PM, Eric Rescorla <[e-mail]> wrote:

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