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

[Marten Seemann <[e-mail]>]

marten-seemann 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

@kazuho There's no such thing as a unified PN space. QUIC has 3 packet number spaces, and there's no way to opt out of that. If a QUIC implementation decides to do weird things with the packet numbers (i.e. if it doesn't start every PN space from 0, as the spec suggests), it shouldn't be surprised to run into additional complexity...

That being said, as you point out in https://github.com/quicwg/base-drafts/pull/2841#discussion_r297128544, we're using a SHOULD elsewhere, so for consistency I changed it to a SHOULD here as well. I don't think that we need a "if it is able to detect the condition" sub-clause here, as the SHOULD already allows you to skip the check, if your implementation is not able to perform it.

-- 
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_r297449947