On Mon, May 15, 2017 at 11:16 AM, Britta Hale <britta.h...@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 > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
