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

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Oct 2018 07:19:29 +0000 (UTC)

This introduces the design that proposed by ekr prior to the NY interim.
In this design, the client advertises the list of versions it supports
in its transport parameters.  The server is permitted to select a
"compatible" version and proceed as though the client selected that
version.

The main advantage of this approach is seamless upgrade between
compatible versions without the extra round-trip imposed by Version
Negotiation.  This will be especially useful when we move from
pre-release versions (0xff0000xx) to the final version.

Closes #1773, #1755.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/1901

-- Commit Summary --

  * Compatible version upgrade

-- File Changes --

    M draft-ietf-quic-transport.md (196)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1901.patch
https://github.com/quicwg/base-drafts/pull/1901.diff

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

---

From: MikkelFJ <[email-masked]>
Date: Wed, 24 Oct 2018 01:29:58 -0700

mikkelfj commented on this pull request.

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

What if the client wants to use a specific other version if possible, but it does not want to do it in-flight within the current connection, for example to keep the client simple? It cannot omit that version from TP because then the current version will continue. It cannot include that version in TP because then it might get in-flight version change.

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

---

From: Marten Seemann <[email-masked]>
Date: Wed, 24 Oct 2018 01:36:59 -0700

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. 

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

---

From: Marten Seemann <[email-masked]>
Date: Wed, 24 Oct 2018 01:38:32 -0700

What’s the use case for this? I don’t really see the point of “keeping the client simple” here, this is not one of the complex areas of the protocol.

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

---

From: MikkelFJ <[email-masked]>
Date: Wed, 24 Oct 2018 01:46:11 -0700

If you implement each version as a separate binary or in a separate process. You could send on the that other version instead and hope the best, but that could result in many unnecessary version negotations if that version is not (yet) widely supported.

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

---

From: MikkelFJ <[email-masked]>
Date: Wed, 24 Oct 2018 01:53:39 -0700

The server might not know that there is a newer compatible version - compatible is both a spec thing and an implementation thing.

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Oct 2018 16:14:18 -0700

@martinthomson pushed 2 commits.

7483395  There are only two things, which means no list
f997b10  Marten's editorial suggestions

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1901/files/4dc5e0d3985972cd45238e62b505f7e8ae15e1b9..f997b10bdbefece517e6667e995cda96b77cc618

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 24 Oct 2018 17:21:57 -0700

kazuho commented on this pull request.

> A client can use the highest (compatible) version, and the server would just downgrade it to the highest version it supports.

It needs to be the lowest version for maximum flexibility.

Consider the case where we would be using 0x81 as the first octet for the Initial packet in QUIC v2, and that we have a client that wants to connect to a server using either v1 or v2. The way to provide room for such possibility is to let the client send a v1 Initial packet with an indication that the server can respond using a v2 Initial packet.

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Oct 2018 18:27:48 -0700

martinthomson commented on this pull request.

Yes, the incentive remains the same - the client offers what it believes to be most widely deployed.  This design only allows for a seamless upgrade to a compatible version.  If the client were to advertise the new, less-widely-deployed version, it risks getting a Version Negotiation packet.

No.  Because the server might not support every compatible version.  If the client offers A, where B is compatible, the server can still send Version Negotiation in response with B because it doesn't understand A.

If you were to implement each version in a different process, then this would not work, yes.  Unless you wanted to complicate the hand-off from a simple `exec quic-vY --disable-vn` to something more like `exec quic-vY --handoff=<translated packet+necessary keys>`.  The consequence is that you probably want to have compatible versions handled by the same instance.

Yeah, and I think that we agreed that the 1232 thing was wrong.  I'll cite 4.3 of the -tls doc instead.

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Oct 2018 18:36:54 -0700

Thinking of versions as being ordered is helpful, but might be constraining.  The point is that the client will use the most widely deployed to start with and accept that the server is able to choose a compatible version.  The client *hopes* that the server will choose a version that it prefers more, but leaves that to the server to decide.

In the case of monotonically increasing versions where A >> B >> C, this might seem obvious, but it's still possible that the client will advertise B and get an apparent downgrade to C.  That's a property of the design that I don't think we'll see that often, but it's nonetheless theoretically possible.

But as @kazuho says, the expected case is a client advertising vN, then being opportunistically upgraded to vN+1.  Like today, you can rely on TLS 1.0 being available widely, but you might prefer TLS 1.3.

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

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 24 Oct 2018 20:32:32 -0700

My understanding is that the intent of the text is to detect version downgrade attack at the server-side instead of doing on the client-side. IMO we need to make the change; see #1810.

However, I am not sure if the proposed design is sufficient, because it only detects a repression of only "one version" (being identified the first entry of supported_versions), while an attacker can inject VN to repress multiple versions.

Consider the case where a client supports three versions, v3, v2, v1 talking to a server that supports v2 and v1. Assume that the use of newer versions are preferable than the older ones. The client uses v3 in it's initial attempt. The attacker intercepts the Initial packet and responds with a fake VN that advertises v1 only. In such case, the server will not notice the downgrade attack and the connection will be established using v1.

IMO, it might make sense to send a list of versions that the client preferred but was unable to use due to the values included in VN that it received.

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Oct 2018 01:11:01 -0700

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Oct 2018 01:54:56 -0700

@martinthomson pushed 1 commit.

f12becd  Thwart downgrade attacks between incompatible versions

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1901/files/f997b10bdbefece517e6667e995cda96b77cc618..f12becdc359d0741ddd8c57abf6ae9485a0530c9

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Oct 2018 01:57:18 -0700

Thanks @kazuho for finding another hole.  That validated the design that @ekr had for this, which separated the first attempted version from the supported versions list.  It turns out that the preference order in the supported versions was necessary to prevent that.  The client needs to tell the server how it would select between common versions so that the choice between incompatible versions can be validated.

This is slightly more complicated, but not much.  Please review the algorithm I put in comments and let me know if you think that would be helpful in documenting the validation process.

-- 
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#issuecomment-432970257

---

From: MikkelFJ <[email-masked]>
Date: Thu, 25 Oct 2018 02:29:28 -0700

Are we sure we want to do this? Usually I'm all for doing things smarter, but it seems like there is a huge attack vector here and a great opportunity for implementations to get things wrong, especially across versions.

-- 
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#issuecomment-432980968

---

From: Nick Banks <[email-masked]>
Date: Thu, 25 Oct 2018 07:51:43 -0700

nibanks commented on this pull request.

Overall looks really good, and I think is a great improvement. Just a few minor comments.

> -selects an acceptable protocol version from the list provided by the server.
-The client then attempts to create a connection using that version.  Though the
-content of the Initial packet the client sends might not change in response to
-version negotiation, a client MUST increase the packet number it uses on every
-packet it sends.  Packets MUST continue to use long headers ({{long-header}})
-and MUST include the new negotiated protocol version.
+selects an acceptable protocol version from the list provided by the server. The
+client MUST choose the version that it most prefers from those supported by the
+server.  The server will abort the connection attempt if the client chooses in a
+manner inconsistent from the preference order included with the client transport
+parameters (see {{version-validation}}).
+
+The client then attempts to create a connection using the version it selects.
+Though the content of the Initial packet the client sends might not change in
+response to version negotiation, a client MUST increase the packet number it
+uses on every packet it sends.  Packets MUST continue to use long headers

Is this saying that even if the client creates an entirely new connection state it needs to increase the packet number still? I assume that wasn't intended. Perhaps `Though the content of the Initial packet the client sends might not change in response to version negotiation, a client MUST increase the packet number it uses on every packet it sends.` should be changed to something like `If the content of the Initial packet the client sends does not change in response to version negotiation, a client MUST increase the packet number it uses on every packet it sends.`?

 The client MUST use the long header format and include its selected version on
 all packets until it has 1-RTT keys and it has received a packet from the server
 which is not a Version Negotiation packet.
 
 A client MUST NOT change the version it uses unless it is in response to a
-Version Negotiation packet from the server.  Once a client receives a packet
-from the server which is not a Version Negotiation packet, it MUST discard other
-Version Negotiation packets on the same connection.  Similarly, a client MUST
-ignore a Version Negotiation packet if it has already received and acted on a
-Version Negotiation packet.
+Version Negotiation packet from the server, or if the server picks a different,
+but compatible version (see {{version-upgrade}}).  Once a client receives a
+packet from the server which is not a Version Negotiation packet, it MUST
+discard other Version Negotiation packets on the same connection.  Similarly, a
+client MUST ignore a Version Negotiation packet if it has already received and
+acted on a Version Negotiation packet.

Is it not theoretically possible that a client (that supports A,B,C) sends version A, and the server supports version {B, C} and responds with a version negotiation packet. THEN the server is updated to support only {C}. The client responds to the VN with B, and then gets a new VN in response, and would want to then try C? It's a pretty crappy experience and extremely small edge case, but I think possible.

> +The format of the packet that a client sends might be different in the new
+version.  In this case, the client generates a new packet that conforms to the
+selected version.  Though different versions might convey information about
+versions differently, a client MUST send both its first attempted version and
+the list of versions it claims to support in preference order.
+
+Version negotiation packets have no cryptographic protection.  Keeping
+version-related information consistent between versions is critical for
+validation of the choice of version (see {{version-validation}}).
+
+
+## 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 includes the version the client first attempts to use, plus

```suggestion
transport parameters include the version the client first attempts to use, plus
```

> +Version negotiation packets have no cryptographic protection.  Keeping
+version-related information consistent between versions is critical for
+validation of the choice of version (see {{version-validation}}).
+
+
+## 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 includes the version the client first attempts to use, plus
+a list of QUIC versions the client supports in the order that the client prefers
+them.
+
+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 version from that list that is

```suggestion
supported versions.  A server MAY choose a version from that list that is
```

> +message sent in the first packet can be used in both versions.  A compatible
+version is also able to identify and acknowledge the first packet sent by the

Should we have some text that says what to do if the server's supported list doesn't overlap at all with the client's? Should it still send a VN, even though it knows the client won't be able to continue the connection? I didn't see any text talking about that case.

-The negotiated_version field is the version that is in use.  This MUST be set by
-the server to the value that is on the Initial packet that it accepts (not an
-Initial packet that triggers a Retry or Version Negotiation packet).  A client
-that receives a negotiated_version that does not match the version of QUIC that
-is in use MUST terminate the connection with a VERSION_NEGOTIATION_ERROR error
-code.
-
-The server includes a list of versions that it would send in any version
-negotiation packet ({{packet-version}}) in the supported_versions field.  The
-server populates this field even if it did not send a version negotiation
-packet.
+is sent by an attacker.
+
+To protect against these attacks, the transport parameters includes both the
+original version the client uses with its first packet, a complete list of

```suggestion
original version the client uses with its first packet and a complete list of
```

> +protection, and allows the server to detect version downgrade attacks.
+
+The client MUST include the first QUIC version it attempts to use in the
+original_version field of its transport parameters.  A server MUST abort the
+connection attempt with a VERSION_NEGOTIATION_ERROR if it supports the version
+in the original_version field and that version does not match the version of the
+Initial packet from the client.
+
+The client MUST include the versions it claims to support in preference order in
+the supported_versions field of its transport parameters.  A server MUST abort
+the connection attempt with a VERSION_NEGOTIATION_ERROR if the Initial packet
+from the client contains a version that is less preferred by the client than any
+version it supports, unless that version also matches the original_version
+field.
+
+<!-- Editor's note: should I include this algorithm?

👍 I find it useful.

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Oct 2018 13:28:52 -0700

4235f75  unplural

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1901/files/f12becdc359d0741ddd8c57abf6ae9485a0530c9..4235f75843f2569cf8d35ad4f5037ceaf8ae8cd1

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Oct 2018 13:28:55 -0700

0e0df73  article

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1901/files/4235f75843f2569cf8d35ad4f5037ceaf8ae8cd1..0e0df7309c39a0e3f259c98e24f5ae65d052afb2

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Oct 2018 13:29:09 -0700

48ae25f  joiner

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1901/files/0e0df7309c39a0e3f259c98e24f5ae65d052afb2..48ae25f21db6ab290ef58997e899b56e5c0c7e16

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Oct 2018 13:46:37 -0700

87bcb71  Nick's suggestions

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1901/files/48ae25f21db6ab290ef58997e899b56e5c0c7e16..87bcb713209742f05cde39cbe162a0e36f19729f

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Oct 2018 14:22:55 -0700

847445b  No common versions means fail
7533873  Move some text up to get the flow right

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1901/files/87bcb713209742f05cde39cbe162a0e36f19729f..75338734ff1c0071f4a5761de51523c061a3cab3

---

From: MikkelFJ <[email-masked]>
Date: Thu, 25 Oct 2018 14:26:35 -0700

Yes, in that case the client should abort and possibly make a completely new connection attempt a limited number of times. Otherwise you can get into a loop between two round robin load balanced servers where you never terminate version negotiation.

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

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 25 Oct 2018 14:52:56 -0700

@martinthomson 
> Thanks @kazuho for finding another hole. That validated the design that @ekr had for this, which separated the first attempted version from the supported versions list. It turns out that the prefer…

I think we agree, though I might say that we do not need a list that lists every versions in the preference order. Just having a way to separate the supported versions into two groups in fine.

IMO, a workable design with minimal change would be use the packet version as a sentinel to divide the supported versions into two groups: a list that contains the versions that the client was not able to choose (due to VN) and a list that contains the other supported versions.

Consider the case where client supports five versions: v1, v1.1, v1.2, v2, v3. Upgrade is possible between different minor versions but not between major versions.

The client, first attempts to connect using v3. The first packet will be a v3 packet. V1.x server responds with a VN that contains v1, v1.2, v1.3.

Then, the client sends an Initial packet in v1, that contains a supported list of (v3, v2, v1, v1.1, v1.2). The server can determine which versions that the client assumed was impossible to use (i.e. v3, v2), because they are placed before v1 which is the packet version.

The benefit of using this "grouping" approach instead of the "total preference order" approach is that it allows the use of the _lowest_ version as the packet format when there are more than one compatible versions. That is generally preferable, because a server can perform a compatible version upgrade only if it can parse the packet format, and using the lowest version provides the maximum chance.

@martinthomson Do my comments sound sensible?

-- 
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#issuecomment-433218454

---

From: MikkelFJ <[email-masked]>
Date: Thu, 25 Oct 2018 15:09:04 -0700

The client is not allowed to respond to version {C} because it is only allow to handle one VN packet (which is important to avoid loops). But as I wrote, a client could make a new connection attempt which amounts to the same thing, so stricly speaking the connection would fail on timeout as the second VN packet is ignored.

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Oct 2018 15:10:00 -0700

I'll take the suggestion, which is better than what we have.  In practice, the packet will probably change - it's a different version of the protocol after all.

This is exactly the type of edge case I had in mind when talking about #504 (now quicwg/ops-drafts#28).

I don't think that we can fix that here, though this compatible version upgrade will make that a lot easier: if B and C are compatible, you can retain enough support for B that you can upgrade from B to C.  It's not perfect, because you still have to send Version Negotiation in response to B if the client doesn't support C, but it could get you further in an incremental roll-back scenario.

That's caught by the generic version negotiation text.  But I note that we don't have that.  #1917.

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

---

From: MikkelFJ <[email-masked]>
Date: Thu, 25 Oct 2018 22:12:26 +0000 (UTC)

Since you wrote this, new text appeared requiring a connection abort if a VN with no overlap is received. If the server has implicit knowledge about what the client supports it doesn't change anything - either it goes forward with a compatible version or it sends a VN packet.

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

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 25 Oct 2018 15:23:32 -0700

Generally speaking, a server cluster will indicate a common subset of versions that it supports in VN.

When adding support for a new version, each of the server start accepting the new version when found in Initial. After that completes, the next would be to modify each server to start indicating the use of the new version in VN.

In case of removing the support for an old version, we will remove that version from the VN list, then stop accepting Initial with that version.

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Oct 2018 15:44:37 -0700

Relying on grouping might work, but it's probably more complicated than necessary.  Maybe something simpler again.  Two lists:

* unsupported_versions is everything the client thinks that the server doesn't support, empty if there wasn't a version negotiation, filled if there was

* supported_versions is every (other) version the client supports

The server validates by seeing if unsupported_versions contains any version that it supports.

supported_versions could be every version the client supports, but that just wastes space, I will expressly allow the client to move items from supported_versions to unsupported_versions to save space.

The nice thing with that is that it forces the client to regenerate the Initial if it gets a Version Negotiation packet (because at least one version will always be added to the unsupported_versions bucket).

-- 
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#issuecomment-433230157

---

From: Marten Seemann <[email-masked]>
Date: Thu, 25 Oct 2018 17:30:43 -0700

@kazuho How does this solve #1810?

> Consider the case where client supports five versions: v1, v1.1, v1.2, v2, v3. Compatible version upgrade is possible between different minor versions but not between major versions.
> The client, first attempts to connect using v3. The first packet will be a v3 packet. V1.x server responds with a VN that contains v1, v1.1, v1.2.

The equivalent to the case you describe in #1810 is the server being upgraded to support v2 just after sending the VNP. When receiving the v1 Initial packet from the client, containing v3 and v2 as impossible versions, it will conclude that an attacker injected the VNP, 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#issuecomment-433248615

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Oct 2018 17:55:20 -0700

@marten-seemann, I assume that the server would upgrade to support v2 in stages similar to what @kazuho suggests in [this comment](https://github.com/quicwg/base-drafts/pull/1901#discussion_r228354726):

That is, the server first starts accepting v2, but not advertising support for it.  In the revised design I proposed, it would also not object if v2 were to appear in unsupported versions during this phase of rollout.

Once all server instances have started accepting v2, then the server can start sending it in Version Negotiation packets.

With the proposed design there is a third phase - once there are no Version Negotiation packets in flight that don't advertise v2, the server can generate errors if unsupported_versions contains v2.

-- 
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#issuecomment-433251999

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 25 Oct 2018 18:11:32 -0700

@martinthomson:
> (snip)

Exactly. I agree that using two lists is the most intuitive way to send two groups of versions.

Two minor things that we might want to clarify:
* Does the version number included in the packet header need to appear in supported_versions? If we are to allow omitting it we should be clear about that.
* Is the server allowed to perform a compatible version upgrade against a version included in unsupported_versions? This could happen during the upgrade process of a server cluster. My slight preference goes to allowing that, because that simplifies the design by making the server the sole entity that detects version downgrade. But people might have different opinions.

-- 
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#issuecomment-433254302

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Oct 2018 18:31:51 -0700

Good questions.  

> Does the version number included in the packet header need to appear in supported_versions?

Yes.  We want this under integrity protection.  We want the union of both lists to include every version the client supports and the client won't ever attempt to connect with a version that it just put in unsupported_versions.

> Is the server allowed to perform a compatible version upgrade against a version included in unsupported_versions?

Yes, and we should allow that to happen.  The client won't care.  It is only splitting the versions into two lists for purposes of detecting a downgrade attack.  This should make the upgrade process easier.  I will call this out explicitly.

Having just written up the text for upgrades, I think that the 

-- 
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#issuecomment-433257233

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Oct 2018 19:23:00 -0700

2b02ccd  Split into supported and unsupported

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1901/files/75338734ff1c0071f4a5761de51523c061a3cab3..2b02ccdc1244a071a62ae99c83ed75ce5d3aa9cb

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Oct 2018 19:33:16 -0700

OK, change implemented.

I realized that we're now relying on different pieces for different capabilities.  We use unsupported versions to protect against a spoofed Version Negotiation packet.  That might lead a client to believe that the server doesn't support a version that it does.

We use the supported versions list and the compatible version upgrade to protect against an attacker rewriting the version of the Initial packet.  That suggests that the server needs to choose, it can't just stay with a version that it doesn't prefer (of course, not choosing is a form of choosing, a server could easily not care).

Then I realized that there is a weakening of our guarantees if we don't record the final version in the transcript, so I put that back.  This is mainly from a surplus of caution.  An attacker could maybe rewrite the version in the server Initial packet and convince the client that the version the server chose was different.  Of course, the version is under integrity protection for later packet types, so this would fail at that point, but it's not great that we don't have the final selection covered by the handshake, so I added it back.  It's not that hard and it makes the integrity protection far more direct.

-- 
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#issuecomment-433266476

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 25 Oct 2018 19:46:07 -0700

-Version negotiation packets have no cryptographic protection. The result of the
-negotiation MUST be revalidated as part of the cryptographic handshake (see
-{{version-validation}}).
+Version Negotiation packet from the server, or if the server picks a different,
+but compatible version (see {{version-upgrade}}).  Once a client receives a
+packet from the server which is not a Version Negotiation packet, it MUST
+discard other Version Negotiation packets on the same connection.  Similarly, a
+client MUST ignore a Version Negotiation packet if it has already received and
+acted on a Version Negotiation packet.
+
+A client MAY attempt 0-RTT after receiving a Version Negotiation packet.
+
+The format of the packet that a client sends might be different in the new
+version.  In this case, the client generates a new packet that conforms to the
+selected version.  Though different versions might convey information about

Aren't we requiring the client to always regenerate a packet, now that `unsupported_versions` change from an empty list to a non-empty list when receiving a VN?

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Oct 2018 19:47:29 -0700

Ahh, I missed that one.  I squashed the other text, but missed that one.

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Oct 2018 19:48:11 -0700

34b19da  The packet definitely always changes

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1901/files/2b02ccdc1244a071a62ae99c83ed75ce5d3aa9cb..34b19daf3aa8921fe0f59358eb5b9c9f5d81316c

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 25 Oct 2018 19:53:31 -0700

+Client and server exchange information about versions along with transport
+parameters in order to protect against version downgrade attacks (see
+{{version-validation}}).
+
+The `supported_versions` field is a list of the versions the client supports.
+This field enables upgrade to compatible versions (see {{version-upgrade}}).  A
+client MAY omit versions from this list if they appear in the
+`unsupported_versions` field.
+
+The `unsupported_versions` field is a list of the versions the client supports,
+but which the client believes that the server does not support.  This list MUST
+be empty unless the client has received and processed a Version Negotiation
+packet.  A client MUST NOT omit a version that it supports from
+`unsupported_versions`, unless the Version Negotiation packet it processed
+listed that version.

I wonder if this _unless_ clause contradicts with the following sentence added above: _Though different versions might convey information about versions differently, a client MUST NOT change the set of versions it claims to support._

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

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 25 Oct 2018 19:54:55 -0700

Yeah! It's a gift to proof-readers :+1:

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Oct 2018 20:02:34 -0700

a2c5c6a  Moar words about what it means for a version to be supported by a client

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1901/files/34b19daf3aa8921fe0f59358eb5b9c9f5d81316c..a2c5c6adf56c764c8843ae7010b724b415268645

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Oct 2018 20:02:57 -0700

Hmm, the text isn't *wrong*, but I'm not sure how to fix it.  The set of versions that a client claims to support is the union of `supported_versions` and `unsupported_versions`.  I've said that, but I think that there's a better way to structure the text to avoid having to say that.

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

---

From: MikkelFJ <[email-masked]>
Date: Fri, 26 Oct 2018 01:25:06 -0700

@kazuho writes 

> Is the server allowed to perform a compatible version upgrade against a version included in unsupported_versions? This could happen during the upgrade process of a server cluster. My slight preference goes to allowing that, because that simplifies the design by making the server the sole entity that detects version downgrade. But people might have different opinions.

I think a downgrade attack is a downgrade attack. If protection is not inherent in the protocol the client must protect itself "manually" which is will not happen reliably.

-- 
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#issuecomment-433329106

---

From: MikkelFJ <[email-masked]>
Date: Fri, 26 Oct 2018 01:28:54 -0700

On the version rollout discussion:

I think it is worth mentioning explicitly as it is a design assumption and it could lead to unexpected results for the unwary.

That said, I believe that in many practical scenarios that are not google scale, you would not see such a careful deployment since it is too much hazzle. You need multiple new versions to deploy and each deployment has a chance of going wrong. So anything that can be done to reduce problems with a single phase rollout would be good.

-- 
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#issuecomment-433330196

---

From: Martin Thomson <[email-masked]>
Date: Fri, 26 Oct 2018 01:32:33 -0700

@mikkelfj 

>> Is the server allowed to perform a compatible version upgrade against a version included in unsupported_versions? [...]
>

This won't be a downgrade attack.  The client has chosen a version that is compatible with the final version, which means that it is up to the server to decide between them.  See quicwg/ops-drafts#52 for an example of how this might happen.  That said, the current text would prohibit that because I didn't allow for that situation fully.  I will remove the text that expressly allows it, leaving it to the upgrade text in the ops draft to cover the corner case.

-- 
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#issuecomment-433331185

---

From: Martin Thomson <[email-masked]>
Date: Fri, 26 Oct 2018 08:35:56 +0000 (UTC)

0de8a0c  Cleanup, don't create conflicting requirements

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1901/files/a2c5c6adf56c764c8843ae7010b724b415268645..0de8a0c7cb88c5f3efff9f403550b9b6d6f568bb

---

From: MikkelFJ <[email-masked]>
Date: Fri, 26 Oct 2018 08:42:11 +0000 (UTC)

I missed that ops text, that was what I was asking for, thanks.

-- 
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#issuecomment-433333837

---

From: MikkelFJ <[email-masked]>
Date: Fri, 26 Oct 2018 02:46:27 -0700

I can't get my head around this sence

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

It is a bit unclear when a client populates other compatible versions: in the first connection attempt, or only as a response to a VN packet. In the latter case the client already has made a choice and the server should not send VN.

On the hande in the first connection attempt the client might want to try v1 with the option of v1.1 and v1.2 as compatible upgrades. It might also want to support v2 but since v2 is not compatible, it cannot say that. But it could hope for v2 in a VN packet. Except, the server is not allowed to do that.

-- 
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#issuecomment-433352263

---

From: Igor Lubashev <[email-masked]>
Date: Fri, 26 Oct 2018 08:12:07 -0700

igorlord commented on this pull request.

> @@ -1168,35 +1168,86 @@ Destination and Source Connection ID fields match the Source and Destination
 Connection ID fields in a packet that the client sent.  If this check fails, the
 packet MUST be discarded.
 
+A client MUST ignore a Version Negotiation packet that lists the client's chosen

```suggestion
A client MUST discard a Version Negotiation packet that lists the client's chosen
```
This is a minor nit.  Let's keep the wording consistent.  Word "discard" was used in a sentence above.

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

---

From: ianswett <[email-masked]>
Date: Fri, 26 Oct 2018 11:02:24 -0700

ianswett commented on this pull request.

Did you intend to drop this in this PR?

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

---

From: ianswett <[email-masked]>
Date: Fri, 26 Oct 2018 11:03:32 -0700

QUIC encodes transport parameters into a sequence of octets, which are then
 included in the cryptographic handshake.

+## Version Validation Fields {#transport-parameter-versions}
+
+Client and server exchange information about versions along with transport

```suggestion
Client and server exchange information about versions in transport
```

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

---

From: ianswett <[email-masked]>
Date: Fri, 26 Oct 2018 11:06:56 -0700

This is not simpler, but I 'think' it works and is complete as written?  That being said, it'd be nice to see someone code this up and see if it holds together in practice.

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

---

From: Ryan Hamilton <[email-masked]>
Date: Fri, 26 Oct 2018 11:22:43 -0700

I'm not a fan of this "compatible version upgrade". It seems to introduce complexity and does not appear necessary. In order of this behavior to be a win over the existing version negotiation mechanism, we need both the client and the server to support both the old and new version. If the client is an HTTP client it should use Alt-Svc to pick the correct best version in which case no version negotiation will happen at all. As such, I have a hard time seeing where we expect this to be used. If we're not doing HTTP, the client can simply cache the last version that server supported and use the best version from that list for the next connection, again typically avoiding version negotiation altogether.

In other words, there's a bunch of complexity here that I really don't see realistic benefits from.) Not to mention, this seems like a rather major piece of new behavior so close to the finish line.)

-- 
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#issuecomment-433500016

---

From: Dmitri Tikhonov <[email-masked]>
Date: Fri, 26 Oct 2018 13:31:07 -0700

I agree with @RyanAtGoogle. I think we should hum this puppy.

-- 
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#issuecomment-433534561

---

From: Marten Seemann <[email-masked]>
Date: Fri, 26 Oct 2018 21:11:29 -0700

I don't agree with @RyanAtGoogle here, for two reasons:

1. The upgrade via Alt-Svc only works for HTTP, other protocols might not have any out-of-band signaling of version support.
2. Caching the last seen version only works for the very big players, like Google and Facebook. For infrequently visited sites, version negotiation will still incur an additional roundtrip.

I don't think this change is too complex to implement, and it provides a real-world benefit to the majority of the QUIC users.

-- 
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#issuecomment-433588894

---

From: ianswett <[email-masked]>
Date: Sat, 27 Oct 2018 04:14:19 -0700

@marten-seemann , I agree with your concern on 2, but in practice, how does the browser even know that a site it hasn't visited before speaks QUIC?

We're definitely straying into implementation details, but I want to get some information about how we expect browsers to try QUIC.  Chrome currently only tries QUIC if it sees Alt-Svc.  Do people think implementations will be more aggressive and always try QUIC along with TCP at some point in the not so distant future?

@MikeBishop, @siyengar and I have discussed whether there are good ways to indicate QUIC support in URLs(ie: httpq?) but nothing so far seems shippable to me.

-- 
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#issuecomment-433611681

---

From: MikkelFJ <[email-masked]>
Date: Sat, 27 Oct 2018 04:35:08 -0700

@ianswett how about the DNS level for indicating QUIC support?

-- 
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#issuecomment-433612943

---

From: ianswett <[email-masked]>
Date: Sat, 27 Oct 2018 04:38:42 -0700

DNS SGTM, but then wouldn't you include the version?

-- 
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#issuecomment-433613165

---

From: MikkelFJ <[email-masked]>
Date: Sat, 27 Oct 2018 04:47:21 -0700

> DNS SGTM, but then wouldn't you include the version?

yeah, I edited my own post after 24s mentioning that.

On DNS, there could also be overlap with LetsEncrypt and possibly FIDO n factor auth, I'm not sure - it seems like there are grounds for a separate standard here perhaps.

-- 
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#issuecomment-433613629

---

From: Kazuho Oku <[email-masked]>
Date: Sat, 27 Oct 2018 21:28:58 -0700

@RyanAtGoogle 
> In other words, there's a bunch of complexity here that I really don't see realistic benefits from.) Not to mention, this seems like a rather major piece of new behavior so close to the finish line…

FWIW, I would like to emphasize that the PR is a composition of a bug fix (#1810) and a new feature (#1773).

Moving downgrade detection to server-side is IMO the most sensible way of fixing #1810, and that is what this PR does by introducing `supported_versions` TP as a parameter of ClientHello. We also need `unsupported_versions` to let the server (within a cluster supporting different set of versions) select the best protocol, though if this is a must-have feature can be debatable.

With those new transport parameters and the behaviors to handle them, the "bug fix" with itself becomes so close to having "compatible version upgrade" as a new feature.

To put another way, my view is that this PR is mostly a bug fix. It is unfortunate that we need to change the downgrade detection mechanism at a late moment, but my view is that we need to, because otherwise version detection cannot be (or at least hard to be) implemented.

-- 
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#issuecomment-433675532

---

From: Martin Thomson <[email-masked]>
Date: Sun, 28 Oct 2018 17:01:44 -0700

8ffb306  discard, not ignore

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1901/files/0de8a0c7cb88c5f3efff9f403550b9b6d6f568bb..8ffb306fec38d9f9ae79b23289c8dd294975c936

---

From: Martin Thomson <[email-masked]>
Date: Sun, 28 Oct 2018 17:04:33 -0700

I have tried to make this separation clearer.  That is, there are transport parameters, and then there is the version negotiation info.  It makes talking about transport parameters easier.

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

---

From: Martin Thomson <[email-masked]>
Date: Sun, 28 Oct 2018 17:15:50 -0700

@RyanAtGoogle, @dtikhonov,

Happy to take this to Bangkok (it's only a week away, after all).  However, I think that you will appreciate the change to having the server validate versions when you walk through the process of upgrading a server to support a new version, even if you don't see the point of the upgrade part of this.

@mikkelfj 
> It is a bit unclear when a client populates other compatible versions: in the first connection attempt, or only as a response to a VN packet. In the latter case the client already has made a choice…

A client populates supported_versions with all versions it supports.  In response to VN, it moves one or more from that list to unsupported_versions.

> On the hand, in the first connection attempt the client might want to try v1 with the option of v1.1 and v1.2 as compatible upgrades. It might also want to support v2 but since v2 is not compatible, it cannot say that. But it could hope for v2 in a VN packet. Except, the server is not allowed to do that.

The client lists v2 in supported_versions.  The server can't use the information, so there is no benefit in  terms of validating version negotiation gained by adding it, but it's easier to describe this way.

I could change supported_versions to compatible_versions and recommend including only those that are compatible with the packet version, but then there is some information absent, and we've only ever regretted that in the past.

-- 
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#issuecomment-433755897

---

From: Martin Thomson <[email-masked]>
Date: Sun, 28 Oct 2018 17:19:48 -0700

@martinthomson pushed 13 commits.

67a815e  Fix the RETIRE_CONNECTION_ID frame type again
4edf5b3  Don't recommend stateless reset
4417e03  Add missing sections to document structure
8f69ad1  Forward reference ECN verification
7c4b04d  Take suggestion
270243e  Use octets rather than bytes throughout
0143d41  Use octets for units; size for packet sizes
bbf55a5  Use bytes instead of octets throughout
a4f4c9f  Reflow
9d50417  Update draft-ietf-quic-recovery.md
3f330f6  clarify
f0b5080  unhypenate - the name of my new startup
4578287  rewrap

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1901/files/8ffb306fec38d9f9ae79b23289c8dd294975c936..4578287e5b5e07728686bc05b82c86d78def4ae5

---

From: Martin Thomson <[email-masked]>
Date: Sun, 28 Oct 2018 18:06:15 -0700

aa3ddc1  Reflow

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1901/files/4578287e5b5e07728686bc05b82c86d78def4ae5..aa3ddc11fcd337703a1c68b1b024b9da2c0b3a53

---

From: Martin Thomson <[email-masked]>
Date: Sun, 28 Oct 2018 19:50:39 -0700

d59f429  Merge branch 'master' into vn-mkII

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1901/files/aa3ddc11fcd337703a1c68b1b024b9da2c0b3a53..d59f4297a5d34ce88356d7b3d2e7eb364244d964

---

From: martinduke <[email-masked]>
Date: Mon, 29 Oct 2018 17:03:22 +0000 (UTC)

As I see it, there are two separable changes here:

1) Moving validation from client to server. The necessary change here is to move the transport parameter from EE to ClientHello. IMO this is no biggie, and addresses the server upgrade problem (i.e. clients can't distinguish between a server pool rolling upgrade and a downgrade attack).

2) Allowing seamless transition between "compatible" versions. This certainly reduces the latency penalty. However this creates a more complicated hierarchy of versions, which is difficult to understand. I also do not feel great that we have though through the implications of taking a v1 packet and acking it in v2. For instance, what if v2 requires a different set of client transport parameters?

I would suggest a separate PR to move the TPs over, which should be merged relatively quickly, and a more extended discussion on seamless upgrade.

If we separate out item (2), however, I think we should retain supported_versions in Encrypted Extensions  purely for next-connection informational purposes (and not for validation).

-- 
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#issuecomment-433991544

---

From: Mike Bishop <[email-masked]>
Date: Mon, 29 Oct 2018 12:22:09 -0700

MikeBishop commented on this pull request.

The TLS comparison is somewhat inapt, since in TLS you actually do offer your highest (most preferred) version and let the server select a compatible, less-preferred version if it doesn't support that one.  QUIC can't do that because the contents of the Initial aren't invariant.

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

---

From: Ryan Hamilton <[email-masked]>
Date: Mon, 29 Oct 2018 13:58:27 -0700

@martinduke, I agree with your framing. Change 1 seems non-controversial. (Interestingly, we've had client-side QUIC downgrade detection since day 1 and have not had problems with spurious detection, but nonetheless this seems like a fine change.) Change 2 is a different story.

-- 
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#issuecomment-434077199

---

From: David Schinazi <[email-masked]>
Date: Wed, 31 Oct 2018 20:29:25 -0700

I agree with @martinduke. Making downgrade prevention more secure is important to QUICv1. However, I'm not yet convinced that "compatible version upgrade" makes sense as part of QUICv1. I think there are two use-cases for it:
1) Upgrade from QUICv1-draft to QUICv1-RFC
In this scenario we can safely assume that the relevant QUIC versions are compatible. However, we can also safely assume that the only deployments of QUIC will be HTTP. Therefore we can rely on Alt-Svc, and have no strong motivation for this mechanism.
2) Upgrade from QUICv1 to QUICv2
In this scenario we're not sure the versions will be compatible, and we also don't have a need to add this to QUICv1. If during design of QUICv2 we want this feature (and I personally believe we will), then we can add a QUICv1 extension indicating support for seamless upgrade to v2, and have browsers try v1 first.

To be clear, I really like this solution - I think it's elegant and efficient. However, it also adds complexity - do we really need it in v1?

-- 
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#issuecomment-434919277

---

From: Marten Seemann <[email-masked]>
Date: Wed, 31 Oct 2018 20:36:08 -0700

> 1. Upgrade from QUICv1-draft to QUICv1-RFC

This is not true. I'm deploying QUIC draft versions in IPFS already, and who knows what other people are doing...

-- 
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#issuecomment-434920297

---

From: David Schinazi <[email-masked]>
Date: Wed, 31 Oct 2018 21:07:18 -0700

Thanks @marten-seemann, that's interesting (and news to me). I'm not familiar with IPFS at all but, out of curiosity, how do your IPFS endpoints let each other know that they support QUIC? Does that mechanism have a way to communicate versions?

-- 
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#issuecomment-434924428