Draft: draft-ietf-quic-transport

Commentary: instead of saying servers SHOULD NOT attempt to parse unknown versions , stick with the factual statement that they will likely be unable to do so . Flips the SHOULD to the second half of the sentence , the expected response . I believe this is editorial , since we 're not modifying expected behavior , but it 's touching normative language , so please speak up if you 're not convinced . 
 Actually , it seems like there should be a normative MUST NOT attempt . 
 I would have said " can not " . The contents are unknown , after all . Attempting to prohibit someone from doing something impossible seems like it might be unnecessary ( or at least futile ) . Edit : of course , this change avoids having to deal with that question , which is better . 
 Why do you say it 's impossible ? You could simply hope that version n+1 was the same as version n in terms of structure and try to parse it as that , ignoring the version number . 
 Which is why the PR says " unlikely , " not " impossible . " But the impossible thing is for the server to know whether it 's doing things correctly . 
 Right , but my point is that we should prohibit trying , not just give people advice that it 's dumb . 
 ( Broken out of . ) This seems like tuning ? Or is the intention to protect the endpoint from an attack , please explain the SHOULD . 
 encodings for any version - specific field . In particular , different packet protection keys might be used for different versions . Servers that do not support a particular version are unlikely to be able to decrypt the payload of the packet . Servers SHOULD NOT attempt to decode or decrypt a packet from an unknown version , but instead send a Version Negotiation packet , provided that the packet is sufficiently long . I 'm having trouble seeing what 's needed here . The endpoint has received a packet professing to be in a version it does not understand . It ca n't know the semantics or encoding of any field there -- and the paragraph already explains that . Yes , I 'm sure there are potential attacks in interpreting a packet of unknown provenance and unknown semantics against a different set of semantics and expectations , but I 'm not convinced we need to explain them . The text recommends sending a Version Negotiation packet , which seems like the only sensible response . 
 This refers to . 
 I 'm looking for two things : ( i ) I think this ought to clarify the intention for the SHOULD , I suspect it is clear to those working on this part , but not clear to me why this is a recommendation - i.e. , specifically can you give me a use - case of why the Server would otherwise USE information from a packet from an unknown version , unless the intention is to say the server should n't waste resources to do try to do this ? ( ii ) I think this implies understanding of Section 14.1 later in the spec , and a ref would help . So ... Is it equally true that .. " Servers MUST NOT use the contents of a packet with an unknown version , and SHOULD NOT decrypt this packet , but instead send a Version Negotiation packet , provided that the packet is sufficiently long ( see Section 14.1 ) . " ? Or perhaps simply explain something like : " Servers SHOULD NOT commit resources to attempt to decode or decrypt a packet from an unknown version , but instead send a Version Negotiation packet , provided that the packet is sufficiently long ( see Section 14.1 ) . " ? 
  , it 's a caution against assumptions which could prove incorrect , such as " this looks like an unencrypted TLS ClientHello , so I can go find the field that contains .... " The server will either process information in a way that could be used maliciously , or the server will generate a response that wo n't be understood by the client . Ideally , this would be a MUST , except that it 's entirely unenforceable by the client what the server does internally . Perhaps the right solution here is to remove the normative language with regard to that piece and stick to the statement of fact we already have : 
 That approach seems fine .
Paragraph (version A):
The first packet for an unsupported version can use different
semantics and encodings for any version-specific field.  In
particular, different packet protection keys might be used for
different versions.  Servers that do not support a particular version
are unlikely to be able to decrypt the payload of the packet.
Servers SHOULD NOT attempt to decode or decrypt a packet from an
unknown version, but instead send a Version Negotiation packet,
provided that the packet is sufficiently long.
Paragraph (version B):
The first packet for an unsupported version can use different
semantics and encodings for any version-specific field.  In
particular, different packet protection keys might be used for
different versions.  Servers that do not support a particular version
are unlikely to be able to decrypt the payload of the packet or
properly interpret the result.  Servers SHOULD respond with a Version
Negotiation packet, provided that the datagram is sufficiently long.