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

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Apr 2017 17:23:50 -0700

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.

-- 
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

---

From: Victor Vasiliev <[email-masked]>
Date: Sun, 23 Apr 2017 14:41:59 -0700

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.

-- 
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-296490822

---

From: Martin Thomson <[email-masked]>
Date: Sun, 23 Apr 2017 16:18:26 -0700

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.

-- 
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-296496236

---

From: Victor Vasiliev <[email-masked]>
Date: Sun, 23 Apr 2017 16:54:38 -0700

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.

-- 
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-296498166

---

From: ekr <[email-masked]>
Date: Sun, 23 Apr 2017 17:10:00 -0700

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