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

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

With the merger of stream 0 DT proposal, we now allow uncoordinated middleboxes to change the server's CID.

While I understand that it is beneficial to allow the existence of such middleboxes on certain deployments, I think that we should require (or provide a way for) other deployments to check that the client's initially chosen DCID field has not been tampered by a middlebox.

Below is a copy of https://github.com/quicwg/base-drafts/issues/1451#issuecomment-399317602 discussing the possible security and ossification concerns behind the issue.

> The issue about simply allowing the existence of an uncoordinated middlebox is that it becomes impossible for any server to detect somebody on-path altering the handshake traffic.
> 
> For example, a middlebox can alter the server CID by sending a Retry, and the server will not notice the alternation if the middlebox also drops the token field of the 2nd Initial packet sent from the client that traverses through the middlebox to the server.
> 
> While I understand that you cannot care about the issue in the deployments that you are interested in, I think that others would be worried about the possible impact on security as well as the ossification concern including the one that I have described in #1451 (comment).
> 
> Fortunately, there are ways to define a signal for detecting tampering that can be implemented by server operators who will not have uncoordinated DOS detection devices.
> 
> One way is to add an "Original_DCID" field to Transport Parameters, and state that "a server SHOULD check that the value of the Original_DCID field matches that of the packet that it saw in the first packet that belonged to the connection". Servers running behind an uncoordinated middlebox will turn this check off.
> 
> Note that having a configuration knob is mandatory for servers running behind such a middlebox, even if we do not introduce the "Original_DCID" field. This is because Retry is version-specific (which means that uncoordinated DOS mitigation devices might need to send a Version Negotiation packet). To support that, the servers need to have a knob that changes how the downgrade protection logic works (FWIW, end-to-end version downgrade protection is currently a MUST; we need to change it as well to allow the existence of uncoordinated DOS mitigation devices).

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

---

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

relates to: #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/1486#issuecomment-400535685

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Jun 2018 21:46:54 -0700

The current design allows for considerable flexibility in routing up until the point that the first Handshake packet commits to a set of connection IDs.  Part of that flexibility allows for changing the connection ID.

A server could decide to validate changes using the token it passes to clients in Retry packets, if it chose to do so.  This could validate the entire sequence of changes, at a modest cost in bytes.

The only protection a client has is that packets from Handshake on are authenticated with end-to-end keys.  An attacker can't modify these packets.  If the client doesn't change its opinion about its connection ID - and it has no reason to do so that I'm aware of - then an attacker can't change the client connection ID value without causing packets to be dropped eventually.

The server has the same protection available, though our design allows multiple options for a server to change connection IDs.  So the only value that is authenticated is the final value, which might not have been reached honestly if - for example - an attacker has used spoofed Retry packets to route the client to a sub-optimal server instance.

If the goal here is to authenticate the chain of connection IDs that are used, starting from the randomized value selected by the client, then it needs to cover more than a single value.

-- 
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/1486#issuecomment-400541391

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 26 Jun 2018 22:06:12 -0700

> A server could decide to validate changes using the token it passes to clients in Retry packets, if it chose to do so.

My point is that it cannot.

Consider the following case:
* a middlebox intercepts the 1st Initial, drops it, and sends back a Retry that contains a 8-octet SCID field that has the value that the middlebox wants
* client sends an Initial packet with the updated server CID and token found in the Retry
* the middlebox trims the Retry field, re-obfuscates the Initial packet and forwards it to the server

The initial packet being altered by a middlebox will look as if it was a Initial packet without a token sent from a client. A server cannot tell if the Destination CID field of the Initial packet was generated by the client or by a middlebox.

-- 
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/1486#issuecomment-400543918

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 Jun 2018 06:01:25 +0000 (UTC)

Ahh, though it's only the first one, that might be enough.  Not sure how much this matters, but we should do something, even if that is only write this down.

-- 
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/1486#issuecomment-400552508

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 27 Jun 2018 00:19:18 -0700

> Ahh, though it's only the first one, that might be enough. Not sure how much this matters, but we should do something, even if that is only write this down.

Yes.

Consider you want to build a middlebox that verifies Client Hello. What you might do is:
* precompute AES-CTR for a special 8-octet CID (e.g., 0000000000000000)
* send a Retry packet that contains the special CID in the source CID field and a zero-length token for every Initial packet that does not contain the special CID in the destination CID field

By doing these, a middlebox can skip the cost of AES for decrypting the Initial packet, because the every Initial packet that it forwards will be encrypted using the same bitstream.

I think we should permit the use of zero-length token, because it would be useful for *stateful* path validation.

OTOH, I would like to prevent seeing these kind of hacks being applied by middleboxes (since it is an ossification concern), if the cost of preventing it is marginal. IMO, including initial DCID in TP and requiring the servers to validate the value when possible meets that goal.

-- 
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/1486#issuecomment-400568727