Subject: [TLS] Comments on EndOfEarlyData

From: Britta Hale <[email-masked]>
Date: Mon, 15 May 2017 17:16:03 +0200

On the Sunday 30/05 TLS:DIV workshop there was mention of the
EndOfEarlyData message and its status as a handshake message or alert
message.

The main argument mentioned for making EndOfEarlyData a handshake
message is that alert messages usually signal "abortive closure of the
connection" (e.g. fatal alerts). Having an EndOfEarlyData alert could be
misleading (i.e. possibly implying that a session is ending instead of
beginning).

However, this intuition is incorrect. Alerts signal the end-of-use of
keys, not the prohibition of further communication under other keys.
Keys should be deleted and no further data should be sent on the
connection. For TLS 1.2 (7.2.1) it is even made explicitly clear that
session resumption is possible after a close_notify send/receipt.

It seems natural then to make EndOfEarlyData an alert message,
signifying end of 0-RTT data. Specifically, the 0-RTT handshake is
followed by 0-RTT data and finally an EndOfEarlyData alert to end use of
that key, while in parallel the remainder of the handshake and
subsequent session key act almost as a further resumption (i.e. under a
different key).

Making EndOfEarlyData an alert message also allows for clear key
boundaries: if EndOfEarlyData is a handshake message, then we are mixing
messages protected by the the client_early_traffic_secret and
handshake_traffic_secret in the Finished message.

---
Britta

---

From: Richard Barnes <[email-masked]>
Date: Tue, 16 May 2017 13:43:32 -0400

> subsequent session key act almost as a further resumption (i.e. under a

As has been pointed out elsewhere, other key changes are signaled with a
handshake message (KeyUpdate), so using a handshake message seems more
natural from a protocol point of view.

> handshake_traffic_secret in the Finished message.

The Finished MAC already mixes data from two different traffic keys
(client/server) and data aren't encrypted at all (ClientHello /
ServerHello).  If you want to argue that the client and server handshake
keys are related by both being derived from the handshake_traffic_secret,
you could just as well argue that all three keys are related by all being
derived from EarlySecret.

--Richard

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

---

From: Nico Williams <[email-masked]>
Date: Tue, 16 May 2017 13:30:30 -0500

> natural from a protocol point of view.

And as long as the record type goes in the clear, sending these sorts of
messages all with the same record type (handshake) seems best from a
traffic analysis p.o.v.

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 May 2017 12:04:57 -0700

> messages all with the same record type (handshake) seems best from a

Actually at this point in the handshake the record type is encrypted.

-Ekr

---

From: Nico Williams <[email-masked]>
Date: Tue, 16 May 2017 14:21:31 -0500

> Actually at this point in the handshake the record type is encrypted.

Oh good.