Protect application data and validate remembered 0-RTT limits
07DATAGRAM application data uses QUIC’s protected application-data keys. Early data can use a remembered server receive limit, but resumption must preserve the relevant limit checks and application replay policy.
The client stored 1200 but receives1000 in this illustrated accepting handshake. It must terminate with PROTOCOL_VIOLATION rather than silently continue with the reduced limit.
Source for this drawing: RFC 9221 · Read RFC section 6 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
- 0-RTT
- Early application data based on remembered state, without replay protection.
- 1-RTT
- Application-data protection after the ordinary handshake key progression.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
DATAGRAM data MUST be protected with 0-RTT or 1-RTT keys. Application protocols allowing DATAGRAM in 0-RTT require a profile defining acceptable 0-RTT use.
- DATAGRAM data MUST be protected with 0-RTT or 1-RTT keys. Application protocols allowing DATAGRAM in 0-RTT require a profile defining acceptable 0-RTT use.
- The ordinary example uses 1-RTT keys. DATAGRAM application data is not sent in Initial or Handshake packets, which do not provide these application-data protection contexts.
- A client MAY store the server’s max_datagram_frame_size with 0-RTT state. That remembered nonzero value lets it send within the old limit before receiving the new handshake parameters.
- A server accepting 0-RTT MUST send a value at least as large as the value associated with the connection that issued the ticket. The example grows 1200 to 1500, satisfying that requirement.
- A client storing the limit with 0-RTT state MUST check that the new handshake value is not smaller. If it is smaller, the client MUST terminate with PROTOCOL_VIOLATION; the example’s1200-to 1000 reduction fails.
- 0-RTT lacks replay protection. Applications must define acceptable early-data use under RFC 9001 section 5.6 rather than treating encrypted datagrams as automatically safe for irreversible operations. Loss-dependent behavior may also reveal datagram use to an on-path packet-dropping adversary.
The remembered limits and replay discussion are distinct from transport reliability: neither 0-RTT nor1-RTT creates a DATAGRAM delivery guarantee. This schematic resumption example assumes an application profile permitting the chosen early data. It does not claim actual session tickets, keys or handshakes were generated.
Read the RFC section ↗