On 05/16/2017 05:57 PM, Britta Hale wrote: > It is a matter of consistency not aesthetics, and that has actual > implications on analysis.
I think there are some unsupported (and unstated!) assumptions about what framework in which to analyze things going on here. > 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. For truncation attacks, maybe alert makes more sense. In the area of advancing the state machine without terminating the connection, handshake makes more sense. You are talking as if there is a single right answer without stating your assumptions; you need to say more about what you are assume and what analyses hinge on such assumptions if you want your argument to carry much weight. > 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. The location in the handshake hash is well-specified in the "The Transcript Hash" section -- it comes after server Finished. It looks like we need to update the preceding table covering base key generation to match, though. -Ben
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
