Draft: draft-ietf-tls-tls13

Commentary: 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  should mirror whatever signedcertificatetimestamp does ) . Also , that servername is just its own kind of mess , where what is the proper thing is n'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 )  ( statusrequest ) supportedgroups usesrtp heartbeat (  ) ( 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 . Do n'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   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 ) .
Paragraph (version A):
All of the parameters for the 0-RTT data (symmetric cipher suite,
ALPN, etc.)  MUST be those which were negotiated in the connection
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.
Paragraph (version B):
The parameters for the 0-RTT data (symmetric cipher suite, ALPN,
etc.) are the same as those which were negotiated in the connection
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.
Paragraph (version A):
The use of "signed_certificate_timestamp" RFC6962 MUST be
identical but the server's SCT extension value may differ.
Paragraph (version A):
The "padding" extension RFC7685 MUST be ignored for this purpose.
Paragraph (version A):
The server MUST have accepted a PSK cipher suite and selected the
first key offered in the client's "pre_shared_key" extension.
Paragraph (version A):
The values of "key_share", and "early_data", which MUST be as
defined in this document.
Paragraph (version B):
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.
Paragraph (version B):
The TLS version number, symmetric ciphersuite, and the hash for
HKDF.
Paragraph (version B):
The selected ALPN RFC7443 value, if any.
Paragraph (version B):
The server_name RFC6066 value provided by the client, if any.
Paragraph (version B):
Future extensions MUST define their interaction with 0-RTT.
Paragraph (version B):
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.