Subject: Version negotiation: the bare minimum?

From: Watson Ladd <[email-masked]>
Date: Wed, 10 Mar 2021 13:54:57 -0800

Dear WG,

I'd like to proffer the world's simplest version negotiation scheme,
based on comments heard during the meeting today from a number of
people.

The following weak assumptions are made: the client has a set of
versions. The server has a partial ordering on versions: this means
that versions are not necessarily preferred over each other (consider
experiments where we will do what the client offers first), but the
relation is transitive. Then the server selection is a function of the
client offered version and supported set.

The client transmits its supported versions and a proffered hello
version in the first packet. The server selects. If that selection is
incompatible they try again with the new selected version transmitted
in VN. If it is compatible, the server selects and proceeds.

The constraint on the handshake is that the supported versions and
offered version and server selection are incorporated on the handshake
in such a way that a mismatch triggers failure, and no two different
versions can derive the same keys. If we assume that e.g. SHA256 is
unbroken this is easy to get.

This only permits a downgrade to a version the server was willing to prefer.

Sincerely,
Watson Ladd

---

From: David Schinazi <[email-masked]>
Date: Mon, 15 Mar 2021 17:18:53 -0700

Hi Watson,

Could you elaborate on your proposal? In particular:
How does the client transmit its supported versions?
What does "compatible" mean?
What does "the server selects" mean?
What does "the server proceeds" mean?

Thanks,
David

---

From: Christian Huitema <[email-masked]>
Date: Mon, 15 Mar 2021 21:11:53 -0700

I have been considering pretty much the same design as Watson. In the 
slide deck that you presented, this would be the "compatible" option. 
The client would select  version X in the QUIC header of the Initial 
packet, and format one or several TP stating:

1) Version in the QUIC header: X

2) Supported compatible versions: Y, Z, T, and maybe Grease. These must 
be "compatible" versions.

The server will:

1) verify that the version in the QUIC header is indeed X. If it is not, 
close the connection with an error.

2) pick one of X, Y, Z or T as the selected version, say Y. 
(Questionable whether the version in the QUIC header should be set to X 
or Y.)

3) Set the TP stating something like "you proposed X and I selected Y"

4) Very optionally, mention in a TP that "this server also supports 
versions V, W." These might be "incompatible" versions.

If none of X, Y, Z, T are supported, the server replies with a VN.

On receiving the server TP, the client verifies that the server saw the 
intended version X, and chose one of the supported version. The client 
might remember additional version V and W for next time, but that's 
extra complexity.

-- Christian Huitema

---

From: David Schinazi <[email-masked]>
Date: Tue, 16 Mar 2021 17:41:56 -0700

Hi Christian,

It seems to me that you're describing what's in the VN draft today.
What am I missing?

David