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