Draft: draft-ietf-quic-transport

Commentary: Remove a sentence ( apparently ) about handling version negotiation packets from the section that 's supposed to be about sending them . Clarify that the handling of version negotiation packets is meant to be specified only by standards - track documents ( since it is in some sense a cross - version invariant rather than version - specific behavior ) . In particular , those documents will not necessarily be specifications for a future version of QUIC . New versions of QUIC specified prior to the existence of a version negotiation mechanism are to respond to Version Negotiation packets in the same manner as v1 . 
 Pushed fixups for both points raised . 
 said : 
 Responded via email . 
 My mistake ; I have n't responded to this DISCUSS yet . I will do so shortly . 
  did so ( shortly ): see 
 said : 
 This is a common question , but I 'm still reluctant to say anything . The best reference I can offer is either or . The former currently does n't really do anything to address this problem , and I 've only a promise to look into this , not even a real commitment to do something . My personal draft is maybe better as the latest version directly addresses the problem , but that had only a lukewarm reception when I presented it and I do n't like downrefs to drafts , especially those that are n't working group items . 
 I guess might have some bearing here as well . 
 It might be done by including information from VN packets in transport parameters of the eventually - selected version , so the endpoints can validate that they selected the proper version after the fact . That 's the most obvious approach . One could also imagine dedicated frame types , something not specific to QUIC , etc . 
 I had something along the lines of  's thought in mind ; " There are multiple mechanisms available by which such authentication could occur , including using transport parameters and the TLS transcript hash to provide mutual agreement on the contents of the version negotiation packet , but no such mechanism is currently defined . " 
 I 'm still reluctant to say that . 
 I 'm labelling this as editorial , since the request was to " add some indication " , which does n't sound like normative text . If someone would like to argue for adding such text , please prepare a PR . 
 I propose close with no action . I 'm fine without the MUST even , but I can see the argument that it is useful in requiring authentication . I do n't see the point in talking about what an endpoint might do ; we have to define that in a future spec . Similar to , is it worth stating that future standards - track spec will describe how to do this authentication ? 
 Okay . While I 'm not opposed to mentioning it , I did look at this text and choose not to propose a change for it as part of . 
 One suggestion , but this is good .
Mailing list commentary: Excision performed in the service of brevity . We have no information , but that indicates more that we have time to work on a solution . I am confident that we have enough of an escape valve that we will be able to define new versions securely . As is the working group ( who I am certain will speak up if they disagree ) . If only we had n't already discussed this at length . I think that we know the answer in the general sense , just not in the specific sense of being able to define the bits and manage operational concerns and other protocol design constraints . The working group reached that confidence . I do n't know how much effort I ' m able to devote now to helping you reach that state . Perhaps other participants would like to offer their help now .
Paragraph (version A):
Version Negotiation packets are designed to allow future versions of
QUIC to negotiate the version in use between endpoints.  Future
versions of QUIC might change how implementations that support
multiple versions of QUIC react to Version Negotiation packets when
attempting to establish a connection using this version.
Paragraph (version B):
Version Negotiation packets are designed to allow for functionality
to be defined in the future that allows QUIC to negotiate the version
of QUIC to use for a connection.  Future standards-track
specifications might change how implementations that support multiple
versions of QUIC react to Version Negotiation packets received in
response to an attempt to establish a connection using this version.
Paragraph (version A):
How to perform version negotiation is left as future work defined by
future versions of QUIC.  In particular, that future work will ensure
robustness against version downgrade attacks; see version-downgrade.
Paragraph (version B):
How to perform version negotiation is left as future work defined by
future standards-track specifications.  In particular, that future
work will ensure robustness against version downgrade attacks; see
version-downgrade.