Change:
the early data.  It is not possible for the server to accept only a subset of the early data messages. <del> [[OPEN ISSUE: are the rules below correct? https://github.com/tlswg/ tls13-spec/issues/451]] It MUST also validate that the extensions negotiated in the previous connection are identical to those being negotiated in the ServerHello, with the exception of the following extensions: </del> <ins> In order to accept early data, the server server MUST have accepted a PSK cipher suite and selected the the first key offered in the client's "pre_shared_key" extension.  In addition, it MUST verify that the following values are consistent with those negotiated in the connection during which the ticket was established. </ins> <del> The use of "signed_certificate_timestamp" RFC6962 MUST be identical but the server's SCT extension value may differ. </del> <ins> The TLS version number, symmetric ciphersuite, and the hash for HKDF. </ins> <del> The "padding" extension RFC7685 MUST be ignored for this purpose. </del> <ins> The selected ALPN RFC7443 value, if any. </ins> <del> The server MUST have accepted a PSK cipher suite and selected the first key offered in the client's "pre_shared_key" extension. </del> <ins> The server_name RFC6066 value provided by the client, if any. </ins> <del> The values of "key_share", and "early_data", which MUST be as defined in this document. </del> <ins> Future extensions MUST define their interaction with 0-RTT. </ins> If any of these checks fail, the server MUST NOT respond with the extension and must discard all the remaining first flight data (thus

Discussion:
We currently have "identical" but Ilari argues we should have more specific rules
From Ilari: "Here is what I think should match (going through all currently known values and excetions): Version Ciphersuite Protection+PRF, key exchange in allowed values. What to do with servername??? Statusrequest presence (but not contents)??? Statusrequestv2 presence (but not contents)??? Signedcertificatetimestamp presence (but not contents)??? ALP can not be negotiated by any means. 0-RTT Protection+PRF+ALP can not be negotiated. (I think statusrequest and statusrequestv2 should mirror whatever signedcertificatetimestamp does). Also, that servername is just its own kind of mess, where what is the proper thing isn't at all obvious. And here is the list of extensions that are allowed to be negotiated with 0-RTT (parenthesis denotes extensions where things depend on exact handling discussed above). (servername) maxframgmentlength (statusrequest) supportedgroups usesrtp heartbeat (statusrequestv2) (signedcertificatetimestamp) tokenbinding [I-D stage] cachedinfo? keyshare presharedkey earlydata (required for obvious reasons) (Note: applicationlayerprotocol_negotiation is not on this list, very much intentionally, since negotiation of ALP is not possible in presence of 0-RTT. Don't even try)."
More from Ilari: Thinking about it some more, including statusrequest/statusrequestv2/ signedcertificatetimestamp is only useful if one wants to tie the ticket lifetime to parent certificate lifetime. Also, list of things saved for 0-RTT-capable context would be useful. I presume: The context name The PSK key The PSK context Timestamp Expiry time (not needed for 0-RTT) On server side: RTT estimate Allowed key exchanges Negotiated protection Negotiated PRF Negotiated ALP (negotiated via any means, or absence thereof) (Implementation-defined peer identity, not needed for 0-RTT) (Implementation-defined self identity, not needed for 0-RTT) What to do with servername??? (On server side, one can save the rest encrypted into context name).