Subject: [TLS] Pull request for session hash

From: Eric Rescorla <[email-masked]>
Date: Fri, 7 Nov 2014 14:01:27 -0800

I've created a preliminary pull request to adapt the session hash fix for
TLS 1.3
for feedback from the WG.

Points to note:

- IMPORTANT: Because the initial handshake messages are encrypted
  under separate keys from the application data traffic, it seems like we
need
  to have 2 sets of CCS messages or none. In anticipation of removing
  renegotiation (see PR https://github.com/tlswg/tls13-spec/pull/88).
  Based on conversations with Alfredo and Martin, it seemed easier
  to remove them. Warning: analysis needed here.

- I created a separate resumption master secret that is fed into the
  key hierarchy. This makes the description of that simpler but will
  need revisiting if we adopt either Rich's unification of session hash
  and tickets or Karthik's PSK-as-tickets unification, but that seemed
  like a separate issue.

- If we adopt the Update proposal we will also need to split the master
  keys into two directional keys, but that's distinct as well.

- I still need to add the names of the session hash authors t
  acknowledgements.

This will probably need another revision before it is ready for merging, but
I wanted to get it out there for feedback.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 7 Nov 2014 14:18:24 -0800

https://github.com/tlswg/tls13-spec/pull/89

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 8 Nov 2014 00:35:08 +0200

> for feedback from the WG.

Quick comment: I presume "{ServerKeyShare}" in figure 2 should be
"ServerKeyShare" (i.e. not encrypted).
 
>   to remove them. Warning: analysis needed here.

I would say that from implementation safety perspective (at least for
non-D TLS) it is better to do the state transitions implicitly.

Except this could cause fun issues if ContentType is encrypted.

I favor "do it wrong and blow up at runtime" over "do it wrong and
get a security hole". Even if the first would be more complex.

(This can also be used to argue that session hash should not be
restarted on retry, not that I think repeating data is a good idea
anyway).

>   and tickets or Karthik's PSK-as-tickets unification, but that seemed

Oh, on topic of multiple master secrets, which one does TLS-Extractor
get? :-)

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 7 Nov 2014 16:35:09 -0800

On Fri, Nov 7, 2014 at 2:35 PM, Ilari Liusvaara <[email-masked]
> wrote:

> "ServerKeyShare" (i.e. not encrypted).

Good catch. Thanks.

> non-D TLS) it is better to do the state transitions implicitly

This seems like a topic where we're going to have a lot of opinions :)

If we do decide to have the CCS, we would restore the previous CCS
after ClientKeyShare/ServerKeyShare and then put a new one after
each side's Finished. I still have the text in git, so I can bring it back.
:)

> Oh, on topic of multiple master secrets, which one does TLS-Extractor

Also a good catch. I suggest we make a new TLS Exporter MS.

-Ekr

---

From: [email-masked] (Martin Rex)
Date: Sat, 8 Nov 2014 02:21:11 +0100 (CET)

Eric Rescorla wrote:
>   need to have 2 sets of CCS messages or none. In anticipation of removing

Huh?

>From an implementation standpoint CCS being a seperate content type
record that is clearly visible to the record layer is one of the better
ideas of the original SSLv3 protocol.

It reduces the necessity for synchonizing the record layer and
the handshake state machine, and allows having the record layer
concatenate consecutive handshake messages into a single TLS record
automatically on the sender side.
On the recipient side, it allows the record layer to preprocess a batch
of incoming TLS records without having to wait for the handshake message
state machine (some TLS stacks create a seperate TLS record for each
handshake message).

-Martin