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

[Kazuho Oku <[e-mail]>]

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