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

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 Jun 2015 15:23:18 -0700

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.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 Jun 2015 15:24:56 -0700

I see I forgot to provide a link. Here:

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

---

From: Dave Garrett <[email-masked]>
Date: Tue, 30 Jun 2015 21:31:19 -0400

On Tuesday, June 30, 2015 06:23:18 pm Eric Rescorla wrote:
> resumption use compatible ciphers?

https://github.com/tlswg/tls13-spec/compare/master...ekr:WIP_draft_07#diff-9d84740dcc569a0a5a359d0fba461a05R3037
+After the server has received the client Finished message, it MAY send
+a NewSessionTicket message. This message creates a pre-shared key
+(PSK) binding between the resumption master secret and the ticket
+label. The client MAY use this PSK for future handshakes by including
+it in the pre_shared_key extension in its ClientHello
+({{pre-shared-key-extension}}) and supplying a suitable PSK cipher
+suite.
+
+%%% Ticket Establishment
+      struct {
+          uint32 ticket_lifetime_hint;
+          opaque ticket<0..2^16-1>;
+      } NewSessionTicket;

The "suitable PSK cipher suite" & "resumption use compatible ciphers" issues would be simpler if the NewSessionTicket was just bound to a specified cipher suite (or vector of suites, but that's probably not needed). We could just add a cipher suite field here so the server tells the client exactly what it expects.

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 Jun 2015 19:43:04 -0700

On Tue, Jun 30, 2015 at 6:31 PM, Dave Garrett <[email-masked]>
wrote:

> The "suitable PSK cipher suite" & "resumption use compatible ciphers"
> issues would be simpler if the NewSessionTicket was just bound to a
> specified cipher suite (or vector of suites, but that's probably not
> needed). We could just add a cipher suite field here so the server tells
> the client exactly what it expects.

Yes, that's one possibility.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 1 Jul 2015 08:17:07 +0300

On Tue, Jun 30, 2015 at 09:31:19PM -0400, Dave Garrett wrote:
> needed). We could just add a cipher suite field here so the server
> tells the client exactly what it expects.

Except since actual PSKs presumably don't have such restrictions (any
supported ciphersuite ok), any games with ciphersuites the server
plays would be specific to resumption.

I don't see anything wrong with session being resumed with different
ciphersuite in 1.3 (in 1.2 things worked differently, there there
actually might have been problems if ciphersuite changed).

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 1 Jul 2015 08:22:55 +0300

> opinions on this topic would be welcome.

I think that there should be capability for server to fail decrypting
the 0RTT data but still proceed with handshake (informing client of
this fact).

Are parameters here things like symmetric ciphersuite used for 0RTT
encryption? Or something else? I think that even if one uses supported
symmetric ciphers, one could still get decrypt failures.

Or is this the "PSK + 0RTT" vs "DHE + 0RTT" problem (the one remaked
in #3)?

Undecryptable 0RTT becomes practicularly fun when considering how
that would interact with handshake transcripts.

> ameliorated some (though not completely) with a la carte negotiation.

I would place stuff like this into "client sending odd stuff and
getting odd behaviour in response". And with the negotiation the
way it is, I don't see security problem here.

Also, I noted that there isn't EncryptedExtensions for resumption.
Is that message optional (it isn't marked so), or is it just omitted
in pure-PSK case (tho I note that pure-PSK might want to use
extensions that use EncryptedExtensions).

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 Jun 2015 22:33:23 -0700

> the 0RTT data but still proceed with handshake (informing client of

What I had in mind here was that you would be able to fail to decrypt
the 0-RTT data and you fell back to an ordinary 1-RTT handshake
(i.e., if there was client auth, it went in the second flight).

> Or is this the "PSK + 0RTT" vs "DHE + 0RTT" problem (the one remaked

Sorry, I'm not quite following this. Can you rephrase?

> that would interact with handshake transcripts.

That's why I'm thinking that the above is the simpler approach.

> way it is, I don't see security problem here.

Thanks.

> extensions that use EncryptedExtensions).

That's just error on my part. My intent was to make resumption-as-PSK as
much like ordinary handshakes as possible.

-Ekr