First, let me say I'm largely indifferent to this handshake versus alert point, so if the WG wants to flip it back, I'm generally OK with that. With that said, we recently implemented -20 and having it be a handshake message is somewhat cleaner.
On Tue, May 16, 2017 at 8:30 AM, 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. This last sentence seems to reinforce the motivating intuition here, namely that the alert signals the end of the *connection*, and so it's odd to have EOED indicate a key change within a 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. > Indeed, but that's a session, not a connection 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). > I can see how you could look at it this way, but I'm not sure that that's the natural way to look at it. If you're not doing DH, then these are very much derived from the same PSK and the same client-side nonce. 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. Well, we also mix unencrypted traffic into the Finished, right? Does this present a practical problem for analysis? -Ekr 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
