Draft: draft-ietf-tls-tls13

Commentary: Both for 0 - RTT and 1 - RTT . Give NST- and externally - provisioned PSKs more uniform treatment . 
 ping ? It would be good to get some resolution in this space , as it 's somewhat relevant to 
 I guess we could perhaps recommend that external PSKs not be provisioned with a SNI value , since the PSK value itself ought to serve as enough of a lookup key for what the intended communication semantics are . 
 is there a path forward for this ( e.g. , does it need to go to the list ) ? 
 I think this is generally good except for the SNI stuff which conflicts with PR , which we also need to resolve one way or another . What say we land this without those pieces and then when we we will know what to do 
 SGTM . Do you need me to adjust the patch ? 
  , I 'll do it . 
 These actually just seem to make the SNI requirements clearer but no sharper , so merging . 
 The Early Data Indication section contains this sentence : The parameters for the 0 - RTT data ( symmetric   , ALPN protocol , etc . ) are the same as those which were negotiated in the connection which established the PSK . This implies to me that you can only do 0 - RTT where the PSK was established via an earlier connection . In external PSK this is not the case . I do n't think this interpretation was the intention . 
 This is stale text from before we allowed 0 - RTT with external PSK , IIRC . 
 Zero - RTT Data says : But 4.6.1 . New Session Ticket Message says : For consistency , I would like to have the latter in Section 2.2 with the same style . Moreover , I would like to know where this differences of requirements come from . 
 I think 4.2.10 may be more appropriate than 2.2 , as it is closer to where the server is doing the relevant processing . 
 Now 4.2.10 has clear requirements . So , why do n't we remove the same requirement from 2.3 ? additional information MUST be provisioned to both parties :
Paragraph (version A):
The parameters for the 0-RTT data (symmetric cipher suite, ALPN
protocol, 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 B):
The parameters for the 0-RTT data (symmetric cipher suite, ALPN
protocol, etc.) are those associated with the PSK in use.  For
externally established PSKs, the associated values are those
provisioned along with the key.  For PSKs established via a
NewSessionTicket message, the associated values are 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):
In order to accept early data, the server MUST have accepted a PSK
cipher suite and selected 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 A):
The TLS version number and cipher suite.
Paragraph (version A):
The selected ALPN RFC7301 protocol, if any.
Paragraph (version B):
These requirements are a superset of those needed to perform a 1-RTT
handshake using the PSK in question.  For externally established
PSKs, the associated values are those provisioned along with the key.
For PSKs established via a NewSessionTicket message, the associated
values are those negotiated in the connection during which the ticket
was established.
Paragraph (version B):
Each PSK is also associated with at most one Server Name
Identification (SNI) value (Section 3 of RFC6066).  For PSKs
established via the ticket mechanism (NSTMessage), this is the SNI
value (if any) on the connection where the ticket was established.
For externally established PSKs, the associated SNI value (or lack of
value) is set when the PSK is established.  The server MUST ensure
that it selects a compatible PSK (if any) and SNI value (if any).
SNI MUST NOT be negotiated when using a PSK not associated with an
SNI value.
Paragraph (version A):
Any ticket MUST only be resumed with a cipher suite that has the same
KDF hash algorithm as that used to establish the original connection,
and only if the client provides the same SNI value as in the original
connection, as described in Section 3 of RFC6066.