Re: Version negotiation: the bare minimum?

[David Schinazi <[e-mail]>]

Hi Watson and Christian,

Glad to hear you'll be there! Would you also be able to prepare a proposal?
It sounds like you've put some thought into this and it would be great to
have something concrete to discuss.

Thanks,
David

On Tue, Apr 13, 2021 at 12:06 AM Christian Huitema <[e-mail]>
wrote:

>
> On 4/12/2021 10:11 PM, Watson Ladd wrote:
> > On Mon, Apr 12, 2021 at 12:44 PM Lucas Pardue
> > <[e-mail]> wrote:
> >> Hi Watson and Christian,
> >>
> >> Thanks for your input on the topic of QUIC Version Negotiation. The
> thread has fizzled out a bit. The QUIC Version Negotiation interim meeting
> is next week (Wednesday April 20, 21:00 UTC), it would be great if you
> could add some further concrete ideas to the discussion. In particular, if
> you're describing an alternative to what the VN draft has today, there is
> value in us hearing it out because it might help the QUIC WG make progress
> in this area.
> > I would be happy to attend.
>
> I will try to attend too. If I can find the invite and link...
>
>
> >
> >> Kind regards
> >> Lucas
> >> QUIC WG Co-chair
> >>
> >> On Wed, Mar 17, 2021 at 12:42 AM David Schinazi <
> [e-mail]> wrote:
> >>> 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
> >>>>>>
> >>>>>>
> >
>