Re: [quicwg/base-drafts] HOL blocking on Finished (#446)

[ekr <[e-mail]>]

The issue here is about the composability of the handshake and the record layer.

Specifically, the conventional way to analyze the security of a handshake protocol such as the TLS 1.3 handshake is to have it spit out a "session key" with the (or at least one) objective being that if both sides think that the handshake is complete then they will also have matching session keys ([CK01]; defn 1). Because the Finished MAC uses keys which are internal to the handshake (and independent of the traffic keys), then you can prove this fact about the TLS handshake without knowing anything about the record layer behavior and in fact no matter what shenanigans go on at the record layer.

If you don't receive the Finished message and use the receipt of an application-layer record then you don't have this assurance at the server side that the client completed the handshake if you just analyze the handshake itself, so you need to also analyze the application layer. To some extent this is just a barrier to analysis and there are analytic techniques which can handle both the handshake and record layer at once, but it's at least possible to imagine situations in which this would lead to problems. For instance, you might imagine having a protocol which negotiated a very weak record layer MAC (as people sometimes do with SRTP), in which case, you would have a correspondingly weak assertion that the client completed the handshake.

[CK01]     Canetti, R. and H. Krawczyk, "Analysis of Key-Exchange  Protocols and Their Use for Building Secure Channels",  Proceedings of Eurocrypt 2001 , 2001.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/446#issuecomment-296499054