Subject: [quicwg/base-drafts] Client's initial source CID is unauthenticated (#1479)

From: Christopher Wood <[email-masked]>
Date: Tue, 26 Jun 2018 05:35:45 -0700

If I'm reading the latest drafts correctly, the client's chosen source CID, used as destination CID by the server, is unauthenticated. If this is unintentional, perhaps we could address it by shoving the client's initial source and destination CID into the transport parameters?

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

---

From: MikkelFJ <[email-masked]>
Date: Tue, 26 Jun 2018 05:45:26 -0700

It somewhat relates to: https://github.com/quicwg/base-drafts/issues/1451

I suggest the intial CID become empty an a separate nonce is sent instead. This nonce should be verified by retry. But a normal handshake ought to also reflect it back to the client.

I don't have the full overview of how the initial CID is validated today. There is path validation and TP validation, but in principle someone could race a handshake if the initial CID is not verified. That is what the long loop discussion is all about, except here it is race to win a retry.

-- 
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/1479#issuecomment-400294172

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Jun 2018 16:01:36 -0700

It's in the AAD.  What else are you concerned about?

-- 
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/1479#issuecomment-400489814

---

From: Mike Bishop <[email-masked]>
Date: Tue, 26 Jun 2018 16:14:13 -0700

The AAD encrypted with a key that anyone who knows the version of QUIC can derive.  I think the suggestion is that, like VN, the initial DCID should be included in the transport parameters so it can be validated at the end of the handshake to confirm there was no tampering.

-- 
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/1479#issuecomment-400492023

---

From: Nick Banks <[email-masked]>
Date: Tue, 26 Jun 2018 16:24:20 -0700

What is the harm in a middle box (maybe a load balancer?) changing the CID?

-- 
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/1479#issuecomment-400493832

---

From: Marten Seemann <[email-masked]>
Date: Tue, 26 Jun 2018 18:56:16 -0700

I agree that we should put it in the transport parameters. There shouldn’t be any way for middleboxes to tamper with packets, even if that tampering might seem harmless now. 

-- 
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/1479#issuecomment-400517843

---

From: Christopher Wood <[email-masked]>
Date: Tue, 26 Jun 2018 19:00:05 -0700

+1 to what @MikeBishop said. It'd be nice to confirm there was no tampering, even if we think it's harmless as of now.

-- 
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/1479#issuecomment-400518415

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Jun 2018 19:04:17 -0700

If we were going to include the client source connection ID, then we also need to the server connection ID - that isn't authenticated by the handshake either.  Then there are all the connection IDs that the server might have the client cycle through with Retry.

We don't authenticate the IP address in the same way.

-- 
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/1479#issuecomment-400519057

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 26 Jun 2018 19:49:16 -0700

As I have commented on https://github.com/quicwg/base-drafts/issues/1451#issuecomment-399317602, I agree with @MikeBishop that the initial DCID should be included in TP so that it would be validated when possible. The reason is because without validation, a handshake might succeed without noticing tampering by a middlebox.

OTOH, I do not see a reason to protect client's source CID, because client's CID is never allowed to change during the handshake. If the middlebox changes the value, the handshake never ends.

-- 
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/1479#issuecomment-400526048

---

From: Christopher Wood <[email-masked]>
Date: Tue, 26 Jun 2018 20:02:09 -0700

> ... client's CID is never allowed to change during the handshake.

Can you please point me to where this is written? If the assumption is that changing the source CID means the handshake continues indefinitely, then putting it in the TP seems to actually enforce that requirement. In general, I'd like the TP to authenticate as many things in initial packets as possible.

-- 
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/1479#issuecomment-400527950

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 26 Jun 2018 20:49:59 -0700

@chris-wood 
> Can you please point me to where this is written?

My understanding is that the following paragraphs effectively requires that.

> During the handshake, an endpoint might receive multiple packets with the long header, and thus be given multiple opportunities to update the Destination Connection ID it sends. A client MUST only change the value it sends in the Destination Connection ID in response to the first packet of each type it receives from the server (Retry or Initial); a server MUST set its value based on the Initial packet. Any additional changes are not permitted; if subsequent packets of those types include a different Source Connection ID, they MUST be discarded. This avoids problems that might arise from stateless processing of multiple Initial packets producing different connection IDs.
> [4.7. Connection ID Encoding](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#connection-id-encoding)

> If the assumption is that changing the source CID means the handshake continues indefinitely, then putting it in the TP seems to actually enforce that requirement.

To be precise, having client's initial source CID in the TP allows the server to check if the value was consistent during the handshake. Clients naturally check that, by comparing the DCID field of the Initial / Handshake packets that they receive.

That's what is different from having client's initial destination CID in TP; without that, neither the client nor the server can check if the field was tampered by a middlebox.

> In general, I'd like the TP to authenticate as many things in initial packets as possible.

That's a fair point. Though I might argue that we do not necessarily need to include something that is a constant during the handshake. As @martinthomson points out, we do not authenticate IP addresses. To me it seems that the security properties of client's source CID is equivalent to that.

-- 
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/1479#issuecomment-400534297

---

From: Christopher Wood <[email-masked]>
Date: Tue, 26 Jun 2018 20:56:17 -0700

Aha -- thanks! I overlooked the last part of that paragraph requiring endpoints to discard packets with a different source CID. In that case, I'm fine omitting the client initial source CID from TP.

Regarding the IP address authentication, is that statement true considering Retry packets and tokens? Isn't one point of the Retry packet to validate the client source address?

-- 
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/1479#issuecomment-400535132

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 26 Jun 2018 21:30:01 -0700

> Regarding the IP address authentication, is that statement true considering Retry packets and tokens? Isn't one point of the Retry packet to validate the client source address?

Yeah I'd say that the server "validates" the path, but it doesn't "authenticate" the path by asking the client prove that it has selected that IP address (which is impossible for a client to prove when NAT is involved).

-- 
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/1479#issuecomment-400539297

---

From: Christopher Wood <[email-masked]>
Date: Wed, 27 Jun 2018 06:16:49 -0700

Sure, sure. That said, if we had a feasible way to authenticate the source address, I'm sure we'd pursue 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/1479#issuecomment-400667571

---

From: Christopher Wood <[email-masked]>
Date: Wed, 27 Jun 2018 06:17:10 -0700

Closed #1479.

-- 
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/1479#event-1703870717

---

From: Christopher Wood <[email-masked]>
Date: Wed, 27 Jun 2018 13:17:11 +0000 (UTC)

Closing in favor of #1486.

-- 
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/1479#issuecomment-400667674