Change:
4.6. <del> 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. </del> <ins> 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. 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. </ins> When 0-RTT is rejected, all connection characteristics that the client assumed might be incorrect.  This includes the choice of

Discussion:
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 doesn'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 can'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.
NAME I just added text about that to my PR that's targeting .
SG NAME 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 doesn't really apply to QUIC, since we don'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 NAME That confirms my interpretation of how accepting and rejecting is supposed to work. I’ll prepare a PR later.