Draft: draft-wood-tls-external-psk-importer

Commentary: Importantly , add details regarding incremental deployment , and clarify label values for non TCP - based variants of TLS . 
 Fixed in . 
 Fixed in . 
 Both endpoints must adopt importers for interoperability 's sake . 
 Fixed in . 
 " TLS 1.3 supports pre - shared key s / resumption / authentication " 
 Fixed in .
Paragraph (version A):
TLS 1.3 RFC8446 supports pre-shared key (PSK) resumption, wherein
PSKs can be established via session tickets from prior connections or
externally via some out-of-band mechanism.  The protocol mandates
that each PSK only be used with a single hash function.  This was
done to simplify protocol analysis.  TLS 1.2, in contrast, has no
such requirement, as a PSK may be used with any hash algorithm and
the TLS 1.2 PRF.  This means that external PSKs could possibly be re-
used in two different contexts with the same hash functions during
key derivation.  Moreover, it requires external PSKs to be
provisioned for specific hash functions.
Paragraph (version B):
TLS 1.3 RFC8446 supports pre-shared key (PSK) authentication, wherein
PSKs can be established via session tickets from prior connections or
externally via some out-of-band mechanism.  The protocol mandates
that each PSK only be used with a single hash function.  This was
done to simplify protocol analysis.  TLS 1.2 RFC5246, in contrast,
has no such requirement, as a PSK may be used with any hash algorithm
and the TLS 1.2 PRF.  This means that external PSKs could possibly be
re-used in two different contexts with the same hash functions during
key derivation.  Moreover, it requires external PSKs to be
provisioned for specific hash functions.
Paragraph (version A):
Imported keys do not require negotiation for use, as a client and
server will not agree upon identities if not imported correctly.
Thus, importers induce no protocol changes with the exception of
expanding the set of PSK identities sent on the wire.
Paragraph (version B):
For clarity, the following table specifies PSK importer labels for
varying instances of the TLS handshake.
Paragraph (version A):
Recall that TLS 1.2 permits computing the TLS PRF with any hash
algorithm and PSK.  Thus, an external PSK may be used with the same
KDF (and underlying HMAC hash algorithm) as TLS 1.3 with importers.
However, critically, the derived PSK will not be the same since the
importer differentiates the PSK via the identity and hash function.
Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS
1.2, and thereby avoid cross-protocol collisions.
Paragraph (version B):
Recall that TLS 1.2 permits computing the TLS PRF with any hash
algorithm and PSK.  Thus, an external PSK may be used with the same
KDF (and underlying HMAC hash algorithm) as TLS 1.3 with importers.
However, critically, the derived PSK will not be the same since the
importer differentiates the PSK via the identity and hash function.
Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS
1.2, and thereby avoid cross-protocol collisions.  Note that this
does not preclude endpoints from using non-imported PSKs for TLS 1.2.
Indeed, this is necessary for incremental deployment.