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. > > 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 >>> >> >>> >> >>> -- Astra mortemque praestare gradatim
