Check origin support and consistent policy
05A gateway needs origin support before forwarding early requests, and server instances must handle replay risk consistently.
Use consistent replay mitigation. Different safe mitigation mechanisms can still be consistent.
Source for this drawing: RFC 8470 · Read RFC section 6.1 ↗
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
- Consistent mitigation
- Instances do not allow the same replay-sensitive data to be acted on early under conflicting policies.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
A local handshake does not replace agreement across the serving system.
- A gateway MUST NOT forward a request received in early data unless it knows the origin understands Early-Data and correctly generates 425. With uncertain support, it SHOULD delay until its client handshake completes or return 425.
- All instances need consistent handling of replay-sensitive requests. Rejecting TLS early data, delaying HTTP processing or sending 425 are compatible mitigations; instances need not choose identical mechanisms. A server MUST NOT act early if it and another instance could handle the same data inconsistently.
- Under load, a server SHOULD prefer rejecting TLS early data as a whole; generating 425 or 503 may increase retry load. With out-of-order delivery, a server MAY process early requests received after handshake completion only if it can rely on other instances correctly handling their replays.
Three independent policy checks are illustrated: unknown origin support stops early forwarding; known supporting origin permits a marked forward; potentially inconsistent processing across instances stops early application action. None is a universal promise to prevent duplicated effects, traffic analysis or denial of service.
Read the RFC section ↗