Draft: draft-ietf-quic-transport

Commentary: But we managed to hide that in the security considerations . 
 This PR is fine , but I agree with above . I think we should add the exception and a reference to this text in 17.2 . 
 How many other rules do we need to create exemptions for ? What if the Initial contains a bad frame ? What if the CRYPTO frame is too long ? 
 If you do n't want to have the discussion about exceptions , then write SHOULD instead of MUST . 
 I do n't want to go to SHOULD . Because for other packet types , MUST is what we want . And finding and creating exceptions is impossible . So I have a " this permission overrides rules that mandate a connection error " . 
 That 's a good suggestion . I moved it . Then it is more likely to be seen . 
 This issue derives from the efforts of to write an HTTP3 test suite , and outline potential implementation issues when sticking to the spec . Section 17.2 of the transport spec describes the format of long header packets , and says : Reserved Bits : Two bits ( those with a mask of 0x0c ) of byte 0 are reserved across multiple packet types . These bits are protected using header protection ; see Section 5.4 of [ QUIC - TLS ] . The value included prior to protection MUST be set to 0 . An endpoint MUST treat receipt of a packet that has a non - zero value for these bits after removing both packet and header protection as a connection error of type PROTOCOL_VIOLATION . Discarding such a packet after only removing header protection can expose the endpoint to attacks ; see Section 9.5 of [ QUIC - TLS ] . I can see doing that for Handshake or 0 - RTT packets , but for Initial packets that feels risky . Any man - on - the - side can send forged Initial packets , including forged Initial packets with reserved bits set . Do we really intend to say that such packets cause the connection to break ? What if the handshake has already progressed ? My gut feeling is that it is simpler and safer to ignore malformed Initial packets and discard them silently . 
 IIUC , allows endpoints to implement such strategy , quote : Endpoints are permitted to use other methods to detect and attempt to recover from interference with the handshake . Invalid packets may be identified and discarded using other methods , but no specific method is mandated in this document . 
 has correctly identified the escape hatch we left . Initial packets are the only place where this really applies , but it goes much further than just those two bits . 
 Are you saying the MUST is not a real MUST because in the " Security Considerations " there is a suggestion that implementations could deviate ? ? ? IMHO that would be weird , given emphasis on the meaning of MUST . 
 My opinion is : An endpoint MUST send PROTOCOLVIOLATION for 1 - RTT . An endpoint MAY send PROTOCOLVIOLATION or MAY discard the packet for other types . 
 the proposal here is to allow discarding only for Initial . Other types are effectively authenticated .   might not be confirmed in the sense that you have key confirmation and peer authentication , but I ca n't imagine anyone attempting to do anything other than abort if an attacker gets that far ) . 
 I 'm OK with discarding only Initial . 
 I think what says makes sense . This is a " MUST unless " however we can not have that stated at every point . Having a catch - all statement makes sense . I tend to wonder if the catch - all statement should be in the Protected Packets section or in the Error Handling section , but the PR looks good regardless . Thanks for the new text , -- this is good .
Paragraph (version B):
As the AEAD on Initial packets does not provide strong
authentication, an endpoint MAY discard an invalid Initial packet.
Discarding an Initial packet is permitted even where this
specification otherwise mandates a connection error.  An endpoint can
only discard a packet if it does not process the frames in the packet
or reverts the effects of any processing.  Discarding invalid Initial
packets might be used to reduce exposure to denial of service; see
handshake-dos.