Change:
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).

Discussion:
A server MUST validate that the ticket_age is within a small tolerance of the time since the ticket was issued (see replay-time). <del> All of the parameters for the 0-RTT data (symmetric cipher suite, ALPN, etc.)  MUST be those which were negotiated in the connection </del> <ins> The parameters for the 0-RTT data (symmetric cipher suite, ALPN, etc.) are the same as those which were negotiated in the connection </ins> which established the PSK.  The PSK used to encrypt the early data MUST be the first PSK listed in the client's "pre_shared_key" extension.

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

"early_data" extension MUST produce a fatal "bad_record_mac" alert as per record-payload-protection. <del> [[TODO: How does the client behave if the indication is rejected.]] </del> <ins> If the server rejects the "early_data" extension, the client application MAY opt to retransmit the data once the handshake has been completed.  TLS stacks SHOULD not do this automatically and client applications MUST take care that the negotiated parameters are consistent with those it expected.  For example, if the ALPN value has changed, it is likely unsafe to retransmit the original application layer data. </ins> 4.2.7.1.