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

[David Schinazi <[e-mail]>]

Speaking in terms of design principles, [the triple handshake attack](https://mitls.org/downloads/tlsauth.pdf) has taught us that pretty much anything that doesn't land in the key schedule can be abused by an attacker that makes each endpoint think it has a different value. Specifically to QUIC, everything going on in the CRYPTO stream lands in the transcript thanks to TLS 1.3, but there are QUIC-specific fields that don't: in particular the connection IDs and version from long headers. To protect the version, we have [draft-ietf-quic-version-negotiation](https://tools.ietf.org/html/draft-ietf-quic-version-negotiation), but we don't have anything for the Source CID. Therefore I'm supportive of adding a transport parameter that makes sure that it lands in the transcript.

On the other hand, requiring the server to always replace the client-chosen initial destination CID does not provide any security benefits in and of itself. There's nothing preventing the server from determining its replacement CID deterministically from the client-chosen one, for example.

This change would be non-trivial for the Google deployment because, unlike migration, it needs to happen synchronously when establishing the connection. If your communication with load balancers is asynchronous, you can delay sending NEW_CONNECTION_ID frames for migration until you've received enough connection IDs from your load balancer, but delaying the response to a client's initial has a performance cost that we're not willing to pay.

-- 
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-595382011