On Tue, May 16, 2017 at 2:41 PM, Britta Hale <[email protected]> wrote:
> On 16. mai 2017 23:28, Eric Rescorla wrote: > > > > >> Avoiding getting caught on the word "connection", EOED signals the end > of key > >> use like other alerts, which is the central issue. Notably, EOED does > >> not signal key change, unlike a KeyUpdate message or Finished message - > even > >> the name indicates that it is for "end of data". Its behavior is > fundamentally > >> like an alert's, indicating only end-of-key use for application data. > > I'm not sure why you say it doesn't signal a key change: EOED signals the > > transition > > between data encrypted with the early traffic keys and that encrypted > with > > the handshake > > key. > > 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? -Ekr
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
