Keep connection and TLS versions distinct
04Ordinary resumption negotiates for the new connection; TLS1.3 changes response placement and constrains early data.
Prior ALPN h2 and new ALPN http/1.1 do not match. The server must not accept that early data. A matching ALPN alone would not satisfy all other early-data checks.
Source for this drawing: RFC 7301 · Read RFC section 3.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
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
TLS1.3 places server ALPN in EncryptedExtensions after ServerHello. It has no renegotiation; early-data compatibility has separate requirements in §4.3.10. This is protocol-version context, not a formal obsoletion of RFC7301.
Read the updated RFC section ↗RFC7301 makes ALPN a connection property, not a cached session property. In an ordinary resumed handshake, only the new handshake values are considered. This first example sends no early application data.
- RFC7301 makes ALPN a connection property, not a cached session property. In an ordinary resumed handshake, only the new handshake values are considered. This first example sends no early application data.
- RFC7301 describes a TLS1.2-style ServerHello response, visible before handshake encryption. For sensitive identifiers, §5 says they SHOULD NOT be used in TLS configurations that expose them; documents SHOULD recommend against unsafe use.
- In TLS1.3, the server ALPN selection is in EncryptedExtensions, after ServerHello, under handshake encryption (RFC9846 §§4.3,4.4.1). This does not hide the ClientHello offer by itself, and TLS1.3 forbids renegotiation.
- For TLS1.3 early data (0-RTT), the server MUST check that the selected ALPN matches the selected pre-shared key's prior protocol, along with TLS-version, cipher-suite and first-key checks. A mismatch prevents early-data acceptance; an ordinary handshake may still proceed (RFC9846 §4.3.10).
0-RTT means sending early data before the ordinary handshake completes. A pre-shared key is key material established earlier; no key is shown or used here. This comparison is only the ALPN necessary condition, not a complete TLS1.3 early-data or cryptographic implementation.
Read the RFC section ↗