Would we also send an alert on key update? On 16 May 2017 at 11:30, Britta Hale <britta.h...@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). > > 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 > > _______________________________________________ > 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
