Draft: draft-ietf-quic-version-negotiation

Commentary: Section 3.3 states : If the server supports one of the client 's compatible versions , and the server also believes that the original version is compatible with this version , then the server converts the client 's first flight to that version and replies to the client as if it had received the converted first flight . The version used by the server in its reply is refered to as the " negotiated version " . The server MUST NOT reply with a version that is not present in the client 's compatible versions , unless it is the original version . I am looking at implementing that , and I am really puzzled . Take for example    V2 draft , which merely changes the Initial salt . Reprocess the first flight would mean try to parse it with the new salt , and that would fail . Or the " authenticated handshake " draft , which require adding a secret into the Initial AAD , but that secret is only present if the first flight was designed for authenticated handshake . I think that the draft needs to be much more precise about this " compatible version " process . It seems that there are three levels : packets , which should be parsed and formatted according to the version number in the long header , or for 1RTT packets the version number negotiated during the handshake . frames , which generally should be treated independently of the packet format -- unless the target version includes new parameters transport parameters and maybe TLS extensions In    V2 draft , we have a simple case of merely changing the packet format without changing the semantic of frames or parameters , so that 's easy . In the authenticated exchange draft , the peers could update from V1 to V - authenticated , but only if they manage to retrieve the required secret from the TLS extensions or the transport parameter . Is that what reprocess means ? The more I think of it , the more I believe that the " upgrade from V1 to  " process should be defined as part of the  specification . For example ,  spec might say something like " when upgrading from V1 to  , find the Transport Parameter X , Y and Z and use them to initialize  parameters A , B and C. " Maybe that 's part of what a " compatible upgrade " is . 
 Hi where does the word " reprocess " come from ? I do n't see it anywhere in the draft . The draft uses the word " convert " . For example in    v2 draft , you would convert a v1 initial to v2 by decrypting it with v1 initial keys , setting the version to v2 , and re - encrypting it with v2 initial keys . Then you 'd be able to process that new synthetic v2 initial . Of course as an optimization your code can skip the re - encryption and just use the parsed result but the concept is to define a conversion between versions . In the current design , it 's totally possible for the " upgrade from V1 to  " process to be described in the  draft , but it 's not required - that allows us to make two versions compatible even if they were developed concurrently in isolation . 
 gentle ping on this - did the latest update to the draft clarify this for you ? 
 The spec says : If the server supports one of the client 's compatible versions , and the server also believes that the original version is compatible with this version , then the server converts the client 's first flight to that version and replies to the client as if it had received the converted first flight . The version used by the server in its reply is refered to as the " negotiated version " . ( Typo : Should be referred , I think ) The text works , but it relies on the server also believes . My point is that in order to believe , the server has to be able to convert the initial Vi input into the selected  . You may or may not want to outline that . I would prefer if you did . 
 Sounds good , I 'll write up an editorial PR to address this . 
 In it talks about the server picking a compatible version and then converting the first flight . As noted in the definition of compatible , it is not sufficient that the transform exist , it also has to succeed . In the example given , there might be reasons that a conversion could fail ( such as the inclusion of information that is optional and can not be transformed ) . In other words , the version might be compatible but the handshake is not . There are three possible outcomes I see here : eliminates that version from the set of compatible options . The server is free to try another compatible version or just give up and use the offered version . I do n't like this much as it implies a denial of service attack on a server that is willing to try multiple compatible versions . server can regard all attempts at compatible versions to have failed and it could send a Version Negotiation packet in response . I am happier with this , but only marginally . It could hide a genuine error on the part of the client . That error manifests as a performance bug . As clients should not ever offer a handshake that includes a compatible version that ca n't be used , this suggests option 3 ... server regards this as a fatal error . The server uses a signal appropriate to the original version to indicate handshake failure . Ideally , any version that has other versions compatible with it defines an error code for this purpose . 
 Can you elaborate on that ? In my mental model , one of the reasons why conversion could fail is that the client is offering an extension which only works with the original , but not the upgraded version . In that case conversion would fail , even though the two versions are compatible in general . I think this would rule out 3 . the client did n’t do anything wrong , and therefore should n’t receive an error . 
 My view is that either the conversion process should describe how to discard that data or the client should not include it . 
 I agree with here . If the conversion hits something that it does n't know how to convert , which seems possible if you consider the range of options that might exist , then that 's an error . Either client should n't have included it , or the server is ignorant of how the conversion should operate . In most cases I can think of , stuff that is only valid for the original version can just be thrown away when converting . Concrete example of a case that might fail . Say that we change the rules for Initial packets in QUICv2 to make the minimum size of the DCID 10 bytes ( up from 8 in v1 ) . A client that offers a QUICv1 Initial with an 8 - byte DCID would be valid in v1 , but it is invalid in v2 . Thus , the rule might be that the client always provide at least 10 bytes in its DCID . If the client did n't do that , but offered v2 as compatible , it has a bug and the connection should n't proceed . 
 I agree with you , though I 'm not sure what you 're asking in terms of changes to the draft - what 's missing ? Should we define the concept of conversion better to explain that a conversion can not fail - or is this about how the server should react when the client sent something that it knew would fail ? 
 in Section 3.3 seems to just assume that this conversion process works :
If the server supports one of the client's compatible versions, and
the server also knows that the original version is compatible with
this version, then the server converts the client's first flight to
that version and replies to the client as if it had received the
converted first flight.  The version used by the server in its reply
is refered to as the "negotiated version".  The server MUST NOT reply
with a version that is not present in the client's compatible
versions, unless it is the original version.
If the server supports one of the client's compatible versions, and
the server also knows that the original version is compatible with
this version, and the client's first flight is compatible with this
version, then the server converts the client's first flight to that
version and replies to the client as if it had received the converted
first flight.  Note that this conversion process cannot fail by
definition of the first flight being compatible.  The version used by
the server in its reply is refered to as the "negotiated version".
The server MUST NOT reply with a version that is not present in the
client's compatible versions, unless it is the original version.