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

[Christian Huitema <[e-mail]>]

What are the required attackers capabilities in order to mount this attack? Clearly, it can be mounted by a MITM, but MITM can do a lot of creative damage during the initial handshake. Can it be mounted by a Man-on-the-side?

In QUIC V1, we understand that authentication only starts when keys are exchanged. The connection-id attack appears to cause the connection to fail because connection IDs are authenticated in 1-RTT packets. That's bad, but there are many ways for MITM to interfere with the connection set up and cause the connection to fail at 1RTT. Do we really want to do something specific about the connection ID? Isn't that an example of piecemeal solutions that make the design complex without blocking all the holes?

We know the general outline of a stronger solution. It is presented in the authenticated handshake draft: derive a secret from the ESNI key of the server, use that secret to authenticate all initial packets. Doing that will suppress not just the connection ID attack, but also the whole class of "attacks by messing up with initial packets". I would much rather authenticate the handshake that pile up piecemeal solutions.

The working group has decided to push the authenticated handshake work to V2, and to accept that there may be DOS attacks during the initial handshake. Is the connection ID attack so special that we need to delay V1 for 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/3439#issuecomment-595041061