Re: Version negotiation: the bare minimum?

[Christian Huitema <[e-mail]>]

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

On 3/15/2021 5:18 PM, David Schinazi wrote:
> 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
>
> On Wed, Mar 10, 2021 at 1:55 PM Watson Ladd <[e-mail]> wrote:
>
>> 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
>>
>>