Subject: [quicwg/base-drafts] Handling of connection ID in handshake creates corner cases (#843)

From: Christian Huitema <[email-masked]>
Date: Mon, 09 Oct 2017 17:30:53 +0000 (UTC)

I just finished writing a test case to replicate a failure mode that I observed during interop testing. The test case goes as follow:

1) start connection #1 from client to server;

2) nuke connection #1 at the client side because something went wrong, as it often does during interop tests;

3) start connection #2 from client to server, using the same 5-tuple as connection #1.

The good news is that in most case I can make it work, the connection #2 succeeds and the test passes. The bad news is that there is one corner case that creates random failures. After the client sends the Client Initial packet it is waiting for a "server clear text" message, and it can receive either:

* the "server clear text" message generated by the server in response to the client initial packet of connection #2;

* or, a retransmission of the "server clear text" message of connection #1, because it was not yet acknowledged when connection #1 was nuked.

If the client accepts the message from connection #1, it will set the connection ID to the connection #1 value, and the TLS handshake will fail because #1 and #2 used different key shares. So the client really wants to pick the "right" server clear text message. But as far as QUIC is concerned, there is no easy way to tell, since both messages carry a connection ID that is unrelated to the client-chosen initial connection ID.

Do we want to handle that corner case?

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

---

From: Ryan Hamilton <[email-masked]>
Date: Mon, 09 Oct 2017 10:42:09 -0700

In some near future, server "clear text" packets will be encrypted with a
key based on the client's connection ID, I believe. In such a scenario, I
would expect that the message from connection #1 would be ignored by the
client's connection #2 because the packet will not decrypt correctly. Does
that sound right to you?

-- 
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/843#issuecomment-335229908

---

From: Christian Huitema <[email-masked]>
Date: Mon, 09 Oct 2017 18:03:18 +0000 (UTC)

@RyanAtGoogle no, encrypting with the connection ID will not be sufficient. According to the spec, the Client Initial carries the client-chosen initial connection ID, but the Server Clear text carries the server chosen connection ID, which the client is supposed to adopt and then use for all consecutive packets. So the client will read the connection ID from the message header, and use it to decrypt the message. It will work, whether using connection ID #1 or #2.

-- 
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/843#issuecomment-335238314

---

From: Christian Huitema <[email-masked]>
Date: Mon, 09 Oct 2017 11:12:30 -0700

What might work is, look for an ACK Frame in the incoming Server Clear Text, and check that the "largest acknowledged" sequence number matches the sequence number of the client initial packet. Ignore the Server Clear text (and do not update the connection ID) if it does not carry an acknowledgement, or if the acknowledged number does not match the client initial sequence number. But this is not what the spec currently says:
>  5.4.3. Server Cleartext Packet
>
> A Server Cleartext packet uses long headers with a type value of 0x04. It is used to carry acknowledgments and cryptographic handshake messages from the server.
>
> The connection ID field in a Server Cleartext packet contains a connection ID that is chosen by the server (see Section 5.6).
>
> The first Server Cleartext packet contains a randomized packet number. This value is increased for each subsequent packet sent by the server as described in Section 5.7.
>
> The payload of this packet contains STREAM frames and could contain PADDING and ACK frames.

So, if we want to be robust, we may need to update that text: mandate that servers insert an ACK frame in the Server Clear Text, and allow clients to check for presence and value of the ACK frame.

-- 
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/843#issuecomment-335242018

---

From: Ryan Hamilton <[email-masked]>
Date: Mon, 09 Oct 2017 11:54:01 -0700

On Mon, Oct 9, 2017 at 11:03 AM, Christian Huitema <[email-masked]
> wrote:

> @RyanAtGoogle <https://github.com/ryanatgoogle> no, encrypting with the
> connection ID will not be sufficient. According to the spec, the Client
> Initial carries the client-chosen initial connection ID, but the Server
> Clear text carries the server chosen connection ID, which the client is
> supposed to adopt and then use for all consecutive packets. So the client
> will read the connection ID from the message header, and use it to decrypt
> the message. It will work, whether using connection ID #1
> <https://github.com/quicwg/base-drafts/pull/1> or #2
> <https://github.com/quicwg/base-drafts/issues/2>.
>
But if the server packet for connection 1 is encrypted with client
connection ID 1, and the server packet for connection 2 is encrypted with
client connection ID 2, there should be ​no confusion. Of course, if the
server encrypts the packet with the *server* connection ID, then that would
not works, but we would also have off-path attacker problems.

-- 
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/843#issuecomment-335254306

---

From: Christian Huitema <[email-masked]>
Date: Mon, 09 Oct 2017 19:38:45 +0000 (UTC)

Oh, OK. I did not realize that the proposal was to encrypt the entire set of handshake messages with the client's initial connection ID -- a field that is not visible in server messages, or in client's clear text message. Is that really the proposal?

-- 
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/843#issuecomment-335264975

---

From: ekr <[email-masked]>
Date: Mon, 09 Oct 2017 19:43:16 +0000 (UTC)

It is indeed:
https://github.com/quicwg/base-drafts/pull/844

On Mon, Oct 9, 2017 at 12:38 PM, Christian Huitema <[email-masked]

> Oh, OK. I did not realize that the proposal was to encrypt the entire set
> of handshake messages with the client's initial connection ID -- a field
> that is not visible in server messages, or in client's clear text message.
> Is that really the proposal?
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/843#issuecomment-335264975>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABD1oSXEsKFSV-GHrTKz6z48gxBuzzRIks5sqnZDgaJpZM4Py0UN>
> .
>

-- 
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/843#issuecomment-335266000

---

From: Ryan Hamilton <[email-masked]>
Date: Mon, 09 Oct 2017 13:01:12 -0700

> Is that really the proposal?
​It is visible in the client's clear text message isn't it?

-- 
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/843#issuecomment-335270108