Re: [TLS] Comments on EndOfEarlyData

On Mon, May 15, 2017 at 11:16 AM, Britta Hale <britta.hale@item.ntnu.no>
wrote:

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

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.

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

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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>