[quicwg/base-drafts] Timing issues in version downgrade attack prevention (#1810)

[Kazuho Oku <[e-mail]>]

Current design requires the contents of the Version Negotiation packet and the value of the `supported_versions` field of the Transport Parameters to be identical.

In practice, this is a requirement hard to meet.

Consider the case of upgrading the server from a version that supports v1 only to a version that supports v1 and v2.

If a client accesses the server running the old version using v2, it would receive a Version Negotiation packet and retry with a v1 Initial. If the server was upgraded before the v1 Initial is received, then the server will include both v1 and v2 in the Transport Parameters, and the client will terminate the handshake considering that a version downgrade attack has been mounted.

Same issue arises when you have a server cluster. The first Initial (that is responded by a Version Negotiation packet) and the second Initial might be delivered to a different node of a server cluster supporting different set of QUIC versions (note: it is rare to upgrade all the nodes behind a server cluster atomically).

IMO, we should either drop version downgrade attack prevention as a whole (as have been proposed in #1755), or move the detection logic to the server-side (e.g., by requiring the client to include in TP all the versions that it preferred to use rather than the version found in the packet header) so that the server could ignore the timing issues during an upgrade.

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