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

[Marten Seemann <[e-mail]>]

marten-seemann commented on this pull request.



>  
-The first client packet of the cryptographic handshake protocol MUST fit within
-a 1232 octet QUIC packet payload.  This includes overheads that reduce the space
-available to the cryptographic handshake protocol.
+2. The first message MUST include the transport parameters chosen by the client.
+   This enables upgrade to a compatible version (see {{version-upgrade}}).
+
+3. The first message MUST fit within a 1232 octet QUIC packet payload.  This

Isn’t this already implied by 1.?

> -with a VERSION_NEGOTIATION_ERROR error code if version negotiation occurred but
-it would have selected a different version based on the value of the
-supported_versions list.
-
-When an endpoint accepts multiple QUIC versions, it can potentially interpret
-transport parameters as they are defined by any of the QUIC versions it
-supports.  The version field in the QUIC packet header is authenticated using
-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

s/they/it

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

This sentence has some leftover parts, I assume.

> +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
+first entry in the list it receives is supported and does not match the version
+of the QUIC packet.  The server MAY choose to upgrade to a compatible version,
+as defined in {{version-upgrade}}.
+
+Different QUIC versions might define transport parameters, or their equivalent,
+using a different format.  However, the version field in the QUIC packet header
+is authenticated using transport parameters.  The position and the format of the
+version fields in transport parameters therefore 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.
+
+Transport parmeters for QUIC versions that are compatible with this QUIC version

Parameters. 

> +
+## Compatible Version Upgrade {#version-upgrade}
+
+The first packet sent by a client uses a QUIC version selected by the client.
+In this version of QUIC, this packet also includes transport parameters.  Those
+transport parameters include a list of QUIC versions the client supports.
+
+A server that understands the version selected by the client can extract the
+list of QUIC versions and select an alternative version from the list of
+supported versions.  A server MAY choose a compatible version from that list and
+continue the handshake with that version.  The server sends its first packet as
+though it was continuing with the version it selects.
+
+A QUIC version is compatible with this version if the cryptographic handshake
+message sent in the first packet can be used in both versions.  A compatible
+version is also able to identifying and acknowledge the first packet sent by the

s/identifying/identify

> +list of QUIC versions and select an alternative version from the list of
+supported versions.  A server MAY choose a compatible version from that list and
+continue the handshake with that version.  The server sends its first packet as
+though it was continuing with the version it selects.
+
+A QUIC version is compatible with this version if the cryptographic handshake
+message sent in the first packet can be used in both versions.  A compatible
+version is also able to identifying and acknowledge the first packet sent by the
+client in some fashion.  Other QUIC versions might have different constraints in
+determining what is compatible.  In order to facilitate this process, new QUIC
+versions could define a process for transforming the first packet from other
+compatible versions into the equivalent packet in the new version.
+
+Upgrading in this manner allows a server to upgrade without incurring the round
+trip imposed by sending a Version Negotiation packet.  It also allows clients to
+send their first packet using a widely deployed version, without the risk of

There’s no incentive to use a widely deployed version any more. A client can use the highest (compatible) version, and the server would just downgrade it to the highest version it supports. 

> +A QUIC version is compatible with this version if the cryptographic handshake
+message sent in the first packet can be used in both versions.  A compatible
+version is also able to identifying and acknowledge the first packet sent by the
+client in some fashion.  Other QUIC versions might have different constraints in
+determining what is compatible.  In order to facilitate this process, new QUIC
+versions could define a process for transforming the first packet from other
+compatible versions into the equivalent packet in the new version.
+
+Upgrading in this manner allows a server to upgrade without incurring the round
+trip imposed by sending a Version Negotiation packet.  It also allows clients to
+send their first packet using a widely deployed version, without the risk of
+having to use that version with servers that supports a more-preferred version.
+
+A server MUST NOT send a Version Negotiation packet if it prefers a version that
+is not compatible with the version the client initially chose; a server has to
+allow the client to choose between versions that are not compatible.

Do we need some text what a client is supposed to do when it receives a VNP that includes a compatible version to the one it initially selected?

>  
 QUIC includes the encoded transport parameters in the cryptographic handshake.
 Once the handshake completes, the transport parameters declared by the peer are
-available.  Each endpoint validates the value provided by its peer.  In
-particular, version negotiation MUST be validated (see {{version-validation}})
-before the connection establishment is considered properly complete.
+available.  Each endpoint validates the value provided by its peer.  Successful
+validation of transport parameters MUST be completed before a connection is
+considered successfully established.
+
+A client also includes a list of supported versions along with its transport
+parameters.  Transport parameters are carried in the first packet the client
+sends.  Sending the list of supported versions enables upgrade between

s/upgrade/upgrades

-- 
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#pullrequestreview-167781310