Draft: draft-ietf-quic-tls

Commentary: 6 Of the TLS doc says : A server rejects 0 - RTT by rejecting 0 - RTT at the TLS layer . This also prevents QUIC from sending 0 - RTT data . However , this does n't explicitly say that it prevents QUIC from receiving 0 - RTT data . I suspect this is implied , but it might be worth clarifying . I could imagine a server rejecting 0 - RTT data , but attempting to ACK the client 's 0 - RTT packets in order to deliver a congestion signal to the client . I think this would be a rather terrible idea , so it would be nice to explicitly prohibit it . 
 Throughout transport , there is the idea that you MUST not acknowledge packets you ca n't fully process , so this should be against the spec . But it may be worth noting explicitly , probably in transport . 
 Doing it in transport would make sense . Or perhaps in TLS by noting that if 0 - RTT is rejected , 0 - RTT keys must not be generated . 
 I just text about that to my PR that 's targeting . 
 SG If so , can you update the CL description to indicate what issues it closes ? 
 I 'm going so recommend that this be triaged as a design issue , even if it might seem trivial . The prohibition in is the right response . 
 The spec says RFC 8446 says about rejecting 0 - RTT : This does n't really apply to QUIC , since we do n't need a connection that requires us to read the bytes in order . The QUIC equivalent would be to drop all packets of packet type 0 - RTT . 
 It is my understanding the existence of early_data extension in the EncryptedExtensions message indicates if the server has accepted 0 - RTT ( or not ) . Merely dropping the packets is not sufficient . This is because the parameters of a connection depends on if 0 - RTT has been received ; for example , in case of HTTP/3 , until the client receives a SETTINGS frame , the settings of previous connection is applied when 0 - RTT is accepted , whereas the default settings defined by the specification is applied when 0 - RTT is rejected . 
 PS . What I think we need to clarify is that " use and acceptance " of 0 - RTT is communicated the same way as TLS 1.3 , by using the earlydata extension . That includes earlydata extension sent in ClientHello , EncryptedExtensions , NewSessionTicket . 
 Thanks That confirms my interpretation of how accepting and rejecting is supposed to work . I ’ll prepare a PR later .
Paragraph (version A):
A server rejects 0-RTT by rejecting 0-RTT at the TLS layer.  This
also prevents QUIC from sending 0-RTT data.  A server will always
reject 0-RTT if it sends a TLS HelloRetryRequest.
Paragraph (version B):
A server accepts 0-RTT by sending an early_data extension in the
EncryptedExtensions (see Section 4.2.10 of TLS13).  The server then
processes and acknowledges the 0-RTT packets that it receives.
Paragraph (version B):
A server rejects 0-RTT by sending the EncryptedExtensions without an
early_data extension.  A server will always reject 0-RTT if it sends
a TLS HelloRetryRequest.  When rejecting 0-RTT, a server MUST NOT
process any 0-RTT packets, even if it could.  When 0-RTT was
rejected, a client SHOULD treat receipt of an acknowledgement for a
0-RTT packet as a connection error of type PROTOCOL_VIOLATION, if it
is able to detect the condition.
Paragraph (version A):
QUIC extensions MUST describe how replay attacks affects their
operation, or prohibit their use in 0-RTT.  Application protocols
MUST either prohibit the use of extensions that carry application
semantics in 0-RTT or provide replay mitigation strategies.
Paragraph (version B):
QUIC extensions MUST describe how replay attacks affect their
operation, or prohibit their use in 0-RTT.  Application protocols
MUST either prohibit the use of extensions that carry application
semantics in 0-RTT or provide replay mitigation strategies.
Paragraph (version A):
QUIC prohibits the sending of empty "STREAM" frames unless they are
marked with the FIN bit.  This prevents "STREAM" frames from being
sent that only waste effort.