Re: [quicwg/base-drafts] Authenticating connection IDs (#3439)

[Antoine Delignat-Lavaud <[e-mail]>]

> @marten-seemann suggests that forcing a change of connection ID at the server (always? only when there is no Retry?) would be sufficient because all an endpoint needs to do is ensure that the choice they made is retained. I would like to see what @ad-l thinks of that.

It seems a bit brittle to me, for instance it doesn't prevent post-retry adversarial forwarding to a different server with the same token key, which could be used for downgrade as @mikkelfj pointed out. It would play out like this:

```
C->S1 INIT[dcid=X]
S1->A RETRY[token=T,scid=X']
A->S2 INIT[dcid=X]
S2->A RETRY[token=T',scid=Y]
A->C RETRY[token=T, scid=Y]
C->S1 INIT[dcid=Y, token=T] ...
```
That's not a very strong attack by any means but still makes me somewhat uncomfortable.

> If we are to fix this, my choice would be to document the issue and observe that servers can fix it by tying the retry token to their proposed CID. That would implicitly solve Google's issue.

That is also kind of OK but difficult to specify as a requirement - how would implementers interpret something like "you must bind the retry token to the proposed CID"? In practice, they should do something like use the CID as part of the nonce of the ticket encryption, or store it in the stateful token database. Unsurprisingly, I much prefer a mechanism that cryptographically guarantees that the CID is authentic because there is no way for a honest and compliant client to know if the server implements the correct check (the same argument as for the use of the client 1-RTT key before checking the client finished)

-- 
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/3439#issuecomment-595358978