On 17. mai 2017 00:25, Eric Rescorla wrote: >> EOED signals the end of data encrypted with early traffic keys, yes, and >> the next >> message is the Finished message encrypted with the handshake traffic key. >> However, >> the Finished message is not *data*, and use of the application traffic key >> is signaled >> by the Finished message, not EOED. The Finished message, like a KeyUpdate >> message, are >> handshake messages, and both signal the start of a new key use for >> application data. >> > In comparison, EOED signals the end of key use for application data - which >> correlates >> to alert behavior. >> > This seems like a point where reasonable people can differ, especially as > ultimately > the motivation for this change was some sense of architectural consistency. > > To go back to my earlier question: does this change actually present some > analytic > difficulty, or do you just find it unaesthetic? > It is a matter of consistency not aesthetics, and that has actual implications on analysis.
Classifying message types is meaningful in terms of truncation attacks. Under a application traffic secret, a receiver is only guaranteed protection from a truncation if it receives an alert (close_notify). According to the current draft, a server is only guaranteed protection from such an attack for 0-RTT data if it receives a handshake message. Such a difference is sloppy in terms of analysis. Furthermore, there is the inconsistency of placement of the EOED message in the Finished hash. The lack of synchronization of EOED, i.e. not being fixed with respect to the other handshake messages, could complicate analysis in terms of matching server/client transcripts. -- Britta _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
