HOL blocking on Finished

[martinthomson]

The current design creates HOL blocking on the Finished message in some cases. It might be OK not to block on this, but it would require some careful analysis to ensure that we have understood the implications properly.

A safer alternative might be to find other ways to ensure that Finished arrives in a timely fashion, though that could require some contortions on the packet format.

[vasilvv]

It's definitely not OK to not block on this in case when client auth is being used. When client auth is not used, it should be okay, since the record layer MAC should be equivalent in coverage to the contents of the Finished message. If you want, I can attempt to write up what goes into both.

[martinthomson]

This assertion that record layer authentication is equivalent to the Finished message is one that caused cryptographers considerable heartburn. They were unwilling to commit to that being sufficient for key confirmation for a range of reasons.

Your point about client authentication is not so clear-cut. It is arguably possible to have two boolean status values at the server: "is the connection up" and "is the client authenticated", which can lead to a situation where the server can provide some responses even if the client isn't authenticated. Think about those cases where we have post-handshake authentication. There are some things on the server that aren't universally accessible to unauthenticated clients, but maybe not everything.

In the general case though, you are right. Generally, guidance is that a server that has requested that the client authenticate wait until it knows for sure. But we have a lot of servers that request authentication for clients but don't close the connection if the client refuses. That suggests that the above model - while more complex - is at least valid.

[vasilvv]

I've heard a lot of claims about record-layer MAC being insufficient, but so far nobody has articulated said "range of reasons", at least on the WG mailing list.

[ekr]

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 short (and hence 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.

[martinthomson]

Discussed between editors and our conclusion was that this would be nice to fix, but the fixes aren't without costs. Before we do that, we would like to see some evidence that the fix was useful or necessary. That probably means collecting information on how common blocking is and then how much impact removing that blocking would have on performance.

[martinthomson]

Addressed by coalesced packets.