Re: [quicwg/base-drafts] describe how 0-RTT is accepted and rejected (#2841)

[Kazuho Oku <[e-mail]>]

kazuho commented on this pull request.



>  
-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.
+A server rejects 0-RTT by sending a ServerHello without the EarlyDataIndication.
+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 is in
+possesion of the keys to do so.  When 0-RTT was rejected, a client MUST treat
+receipt of an acknowledgement for a 0-RTT packet as a connection error of type

To clarify, what is being discussed here is about how to process ACKs containing invalid packet numbers. The general rule we have is that _an endpoint SHOULD treat receipt of an acknowledgment for a packet it did not send as a connection error of type PROTOCOL_VIOLATION, if it is able to detect the condition_ ([section 13.1.1](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.13.1.1)).

Is there a reason we need something different for 0-RTT packets?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2841#discussion_r297128544