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 <[email protected]> wrote: > > On 4/12/2021 10:11 PM, Watson Ladd wrote: > > On Mon, Apr 12, 2021 at 12:44 PM Lucas Pardue > > <[email protected]> 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 < > [email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 > >>>>>> > >>>>>> > > >
