On Tue, May 16, 2017 at 2:59 PM, Eric Rescorla <[email protected]> wrote:
> 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. > I'm inclined to keep EOED as a handshake message. I also found it cleaner to handle in my implementation than the alert-based alternative, especially using the state machines added recently. --Richard > > > On Tue, May 16, 2017 at 8:30 AM, Britta Hale <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/tls >> > > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
