Re: [quicwg/base-drafts] Compatible version upgrade (#1901)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.



> -transport parameters.  The position and the format of the version fields in
-transport parameters MUST either be identical across different QUIC versions, or
-be unambiguously different to ensure no confusion about their interpretation.
-One way that a new format could be introduced is to define a TLS extension with
-a different codepoint.
+is sent by an attacker.
+
+To protect against these attacks, the transport parameters includes the complete
+list of versions that a client is willing to use, with the version they used for
+sending the first packet in the first entry.  Including this information in the
+cryptographic handshake provides it with integrity protection, and allows the
+server to detect version downgrade attacks.
+
+The client MUST include the first QUIC version it attempts to use as the first
+entry of the supported_versions list in the transport parameters.  A server MUST
+close the connection attempt with a VERSION_NEGOTIATION_ERROR if it supports the

Oh, so that would be the case where the v2 and v1 are not compatible, that is, the server has to respect the client's choice between v1 and v2.  In this case, we're not respecting the client's preferences.  I think that I'll have to take @ekr's design here to fix that.  That is, the client advertises the version it attempts first, then it provides a list in preference order.  Then validation at the server goes thus:

original version is supported, but not the current version = error
client prefers an incompatible version over the current version and the preferred version is supported by the server = error

Does that sound right?

-- 
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/pull/1901#discussion_r228072597