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
> The spec having different packet number spaces does not necessarily mean that every QUIC stack should be having different PN counters for each number space for the packets it sends. It is entirely plausible for a QUIC stack to use just one packet number space for the packets it sends.

The spec is actually quite clear about this (https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.12.3)
>  Packet numbers in each space start at packet number 0.

Now I agree that it's possible to ignore this sentence and start the packet number wherever you want (if you're willing to tolerate the loss recovery response this provokes, i.e. an early ACK because of detected reordering). However, I don't think we need to modify the spec because of self-inflicted complexities of non-compliant implementations.

> IIRC, the sub-clause "if it is able to detect the condition" was added intentionally to the general rule, because people were concerned about the text being interpreted as to recommend having a way to detect such errors.

I think we added this text because for 1-RTT packets, you clear out old ACK ranges from time to time. When receiving an ACK for a very old packet you'd then not be able to check if you actually sent this packet, because you already removed the tracking state.

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