Re: Version negotiation: the bare minimum?

[David Schinazi <[e-mail]>]

Hi Christian,

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

David

On Mon, Mar 15, 2021 at 9:11 PM Christian Huitema <[e-mail]>
wrote:

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