Please correct me if I'm wrong, but it seems to me that people are using "compatible version" as a term to describe packets carrying first-flight initial data (e.g., ClientHello) using QUIC version X to which servers might respond with something other than Version Negotiation packets _nor_ QUIC version X packets.
IIUC, the intention is to allow endpoints start the handshake using QUIC v1 but end up with using something other than QUIC v1, without incurring the cost of one extra round-trip due to Version Negotiation packet being sent by the server. Based on this understanding, I have one question. Do we need such a feature? QUIC v1 already has Transport Parameters that can be used for negotiating how 0-RTT and short header packets would be used. By using Transport Parameters, we can define extensions that add, modify, or remove any feature wrt how application data would be exchanged. The idea of having a mechanism for selecting a QUIC version between "compatible versions" sounds to me like just creating another way of negotiating features using TLS messages as the conveyor. Hence the question. 2021年3月16日(火) 13:12 Christian Huitema <huit...@huitema.net>: > 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 <watsonbl...@gmail.com> > 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 > >> > >> > > -- Kazuho Oku
