Subject: [TLS] PR#812: End Of Early Data as handshake

From: Eric Rescorla <[email-masked]>
Date: Mon, 12 Dec 2016 17:09:22 -0800

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

David Benjamin pointed out to me that end_of_early_data is the only place
where we transition keys on an alert and this would be cleaner if it was a
handshake message. This PR does that. It's encrypted under the same
keys, so this is largely an aesthetic issue, but I think a good one.

Target merge date: Thursday.

-Ekr

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 12 Dec 2016 19:10:43 -0600

On 12/12/2016 07:09 PM, Eric Rescorla wrote:
> It's encrypted under the same

Agreed on both counts.

-Ben

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Dec 2016 12:23:19 +1100

> keys, so this is largely an aesthetic issue, but I think a good one.

The major change in this PR isn't that obvious.  And that is this:

   if the server has accepted early data, an EndOfEarlyData
   message will be sent to indicate [a] key change.

This makes the end of early data signal conditional: a client that
learns that its 0-RTT data has been rejected MUST NOT send the
EndOfEarlyData message.

The reason for this is that the EndOfEarlyData is a handshake message
and therefore part of the handshake transcript.  Presumably it appears
after Finished (I'm going to send a PR that expands the ellipsis in
the draft at least once, so that people can see the full canonical
order).

FWIW, I think that this is the right change, but some implementations
will need to change in some non-obvious ways.

I'm not aware of anyone who is rejecting 0-RTT and then decrypting the
data so they can avoid a bunch of failed decryptions, but that
approach won't work any more.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 12 Dec 2016 17:32:59 -0800

> will need to change in some non-obvious ways.

Thanks for pointing this out. I agree with this assessment. We could of
course
exclude it from the transcript but that seems silly.

> approach won't work any more.

Actually you could, just discard EOED in that mode.

-Ekr

---

From: Nick Harper <[email-masked]>
Date: Mon, 12 Dec 2016 17:43:19 -0800

> exclude it from the transcript but that seems silly.

Right now, I believe it's legal for a client to send ClientHello, early
data, and end_of_early_data alert without reading any messages from the
server. This change would require a client to wait for the ServerHello
before sending (or not) EndOfEarlyData, but that seems quite reasonable.

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Dec 2016 12:45:31 +1100

> before sending (or not) EndOfEarlyData, but that seems quite reasonable.

It's legal to send EndOfEarlyData at any time as long as it follows
the (first) ClientHello, but you are right in observing that it would
be difficult to send it at a different time than when you are entering
it into the transcript.

p.s., It's the Server Finished that you have to wait for, not just ServerHello.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 12 Dec 2016 17:50:37 -0800

> be difficult to send it at a different time than when you are entering

The good news here is that it's empty, so you can just remember it if you
need to.

-Ekr

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 13 Dec 2016 10:52:01 +0900

2016-12-13 10:45 GMT+09:00 Martin Thomson <[email-masked]>:
> the (first) ClientHello,

My understanding is that such action has been banned recently in
https://github.com/tlswg/tls13-spec/pull/806.

Picotls has been doing this (and therefore I would need to change the
code). But nevertheless I support this change and the changes
discussed in this thread, since it would simplify the state transition
on the server side.

>  but you are right in observing that it would

-- 
Kazuho Oku

---

From: David Benjamin <[email-masked]>
Date: Tue, 13 Dec 2016 01:54:50 +0000

> p.s., It's the Server Finished that you have to wait for, not just

I think sending EndOfEarlyData/end_of_early_data late is desirable anyway,
even if you know you won't be sending more 0-RTT data. That forces servers
to get the processing order right:
https://tlswg.github.io/tls13-spec/#rfc.section.4.2.8.1

If by including it in the transcript, we make it more likely that clients
will send in a way that forces correct server behavior, that sounds like a
good thing for the ecosystem.

It also shouldn't be any more complexity for the client to send it later
because the client must already have logic to change keys and send a
Finished message after receiving ServerHello..Finished. The EndOfEarlyData
just tacks before that (as I expect most clients would have implemented the
alert version anyway).

To add to the motivations: EKR mentioned end_of_early_data is the only
place where we transition keys on an alert. Conversely, it's also the only
alert that does not terminate the connection. (The document even currently
claims end_of_early_data is a "closure alert" and signals "that the
connection is ending". This is false.)

David

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 12 Dec 2016 17:56:56 -0800

On Mon, Dec 12, 2016 at 5:54 PM, David Benjamin <[email-masked]>
wrote:

> I think sending EndOfEarlyData/end_of_early_data late is desirable
> anyway, even if you know you won't be sending more 0-RTT data. That forces
> servers to get the processing order right:

FWIW, this is how NSS behaves.

-Ekr