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

Commentary: I do n't love a couple of the ways I phrased things here , so feel free to offer suggestions to improve it ! modulo test vectors . ( it 'll likely take some time to get those vectors . Do you think we should hold this document until that 's done ? ) 
 This looks good modulo the open issue about incremental deployment . I do n't think we need to hold the document up in order to get test vectors .
Paragraph (version A):
versions.
Paragraph (version B):
versions.  In cases where this is not possible, e.g., there are
already deployed external PSKs or provisioning is otherwise limited,
re-using external PSKs across different versions of TLS may produce
related outputs, which may in turn lead to security problems; see
RFC8446, Section E.7.
Paragraph (version A):
Endpoints which import external keys MUST NOT use either the external
keys or the derived keys for any other purpose.  Moreover, each
external PSK MUST be associated with at most one hash function, as
per the rules in Section 4.2.11 from RFC8446.  See security-
considerations for more discussion.
Paragraph (version B):
Endpoints which import external keys MUST NOT use the keys that are
input to the import process for any purpose other than the importer,
and MUST NOT use the derived keys for any purpose other than TLS
PSKs.  Moreover, each external PSK fed to the importer process MUST
be associated with at most one hash function.  This is analogous to
the rules in Section 4.2.11 of RFC8446.  See security-considerations
for more discussion.
Paragraph (version A):
Imported PSK (IPSK): A PSK derived from an EPSK, External
Identity, optional context string, target protocol, and target
KDF.
Paragraph (version B):
Imported PSK (IPSK): A PSK derived from an EPSK, optional context
string, target protocol, and target KDF.
Paragraph (version B):
This document uses presentation language from RFC8446, Section 3.
Paragraph (version A):
ImportedIdentity.context MUST include the context used to derive the
EPSK, if any exists.  For example, ImportedIdentity.context may
include information about peer roles or identities to mitigate
Selfie-style reflection attacks Selfie.  See mitigate-selfie for more
details.  If the EPSK is a key derived from some other protocol or
sequence of protocols, ImportedIdentity.context MUST include a
channel binding for the deriving protocols RFC5056.  The details of
this binding are protocol specific and out of scope for this
document.
Paragraph (version B):
ImportedIdentity.context MUST include the context used to determine
the EPSK, if any exists.  For example, ImportedIdentity.context may
include information about peer roles or identities to mitigate
Selfie-style reflection attacks Selfie.  See mitigate-selfie for more
details.  If the EPSK is a key derived from some other protocol or
sequence of protocols, ImportedIdentity.context MUST include a
channel binding for the deriving protocols RFC5056.  The details of
this binding are protocol specific and out of scope for this
document.
Paragraph (version A):
L corresponds to the KDF output length of ImportedIdentity.target_kdf
as defined in IANA.  For hash-based KDFs, such as
HKDF_SHA256(0x0001), this is the length of the hash function output,
i.e., 32 octets.  This is required for the IPSK to be of length
suitable for supported ciphersuites.
Paragraph (version A):
The identity of "ipskx" as sent on the wire is ImportedIdentity,
i.e., the serialized content of ImportedIdentity is used as the
content of PskIdentity.identity in the PSK extension.  The
corresponding TLS 1.3 binder key is "ipskx".
Paragraph (version B):
L corresponds to the KDF output length of ImportedIdentity.target_kdf
as defined in IANA.  For hash-based KDFs, such as
HKDF_SHA256(0x0001), this is the length of the hash function output,
e.g., 32 octets for SHA256.  This is required for the IPSK to be of
length suitable for supported ciphersuites.  Internally, HKDF-Expand-
Label uses a label corresponding to ImportedIdentity.target_protocol,
e.g., "tls13" for TLS 1.3, as per RFC8446, Section 7.1, or "dtls13"
for DTLS 1.3, as per I-D.ietf-tls-dtls13, Section 5.10.
Paragraph (version B):
The identity of "ipskx" as sent on the wire is ImportedIdentity,
i.e., the serialized content of ImportedIdentity is used as the
content of PskIdentity.identity in the PSK extension.  The
corresponding PSK input for the TLS 1.3 key schedule is 'ipskx'.
Paragraph (version A):
The hash function used for HKDF RFC5869 is that which is associated
with the EPSK.  It is not the hash function associated with
ImportedIdentity.target_kdf.  If no hash function is specified,
SHA-256 SHA2 MUST be used.  Diversifying EPSK by
ImportedIdentity.target_kdf ensures that an IPSK is only used as
input keying material to at most one KDF, thus satisfying the
requirements in RFC8446.  See security-considerations for more
details.
Paragraph (version B):
The hash function used for HKDF RFC5869 is that which is associated
with the EPSK.  It is not the hash function associated with
ImportedIdentity.target_kdf.  If no hash function is specified,
SHA-256 SHA2 SHOULD be used.  Diversifying EPSK by
ImportedIdentity.target_kdf ensures that an IPSK is only used as
input keying material to at most one KDF, thus satisfying the
requirements in RFC8446.  See security-considerations for more
details.
Paragraph (version A):
Endpoints SHOULD generate a compatible "ipskx" for each target
ciphersuite they offer.  For example, importing a key for
TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384 would yield two
PSKs, one for HKDF-SHA256 and another for HKDF-SHA384.  In contrast,
if TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256 are
supported, only one derived key is necessary.
Paragraph (version A):
EPSKs MAY be imported before the start of a connection if the target
KDFs, protocols, and context string(s) are known a priori.  EPSKs MAY
also be imported for early data use if they are bound to protocol
settings and configurations that would otherwise be required for
early data with normal (ticket-based PSK) resumption.  Minimally,
that means Application-Layer Protocol Negotiation RFC7301, QUIC
transport parameters (if used for QUIC), and any other relevant
parameters that are negotiated for early data MUST be provisioned
alongside these EPSKs.
Paragraph (version B):
Endpoints SHOULD generate a compatible "ipskx" for each target
ciphersuite they offer.  For example, importing a key for
TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384 would yield two
PSKs, one for HKDF-SHA256 and another for HKDF-SHA384.  In contrast,
if TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256 are
supported, only one derived key is necessary.  Each ciphersuite
uniquely identifies the target KDF.  Future specifications that
change the way the KDF is negotiated will need to update this
specification to make clear how target KDFs are determined for the
import process.
Paragraph (version B):
EPSKs MAY be imported before the start of a connection if the target
KDFs, protocols, and context string(s) are known a priori.  EPSKs MAY
also be imported for early data use if they are bound to the protocol
settings and configuration that are required for sending early data.
Minimally, that means Application-Layer Protocol Negotiation value
RFC7301, QUIC transport parameters (if used for QUIC), and any other
relevant parameters that are negotiated for early data MUST be
provisioned alongside these EPSKs.
Paragraph (version A):
Recall that TLS 1.2 permits computing the TLS PRF with any hash
algorithm and PSK.  Thus, an EPSK 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 target KDF and protocol.
Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS
does not preclude endpoints from using non-imported PSKs for TLS 1.2.
Indeed, this is necessary for incremental deployment.  Specifically,
existing applications using TLS 1.2 with non-imported PSKs can safely
enable TLS 1.3 with imported PSKs in clients and servers without
interoperability risk.
Paragraph (version B):
The mechanism defined in this document requires that an EPSK is only
ever used as an EPSK and not for any other purpose.  In particular,
this requirement disallows direct use of the EPSK as a PSK in TLS
target protocol and KDF, which in turn protects against cross-
protocol collisions for protocol versions using this process by
ensuring that each IPSK can only be used with one protocol and KDF.
This is a distinct contrast to TLS 1.2, where a given PSK might be
used with multiple KDFs in different handshakes, and importers are
not available.  Furthermore, the KDF used in TLS 1.2 might be the
same KDF used by the importer mechanism itself.
Paragraph (version B):
In deployments that already have PSKs provisioned and in use with TLS
then result in concurrent use of the already provisioned PSK both
directly as a TLS 1.2 PSK and as an EPSK, which in turn could mean
that the same KDF and key would be used in two different protocol
contexts.  There are no known related outputs or security issues that
would arise from this arrangement.  However, only limited analysis
has been done, and as such is not a recommended configuration.
Paragraph (version B):
However, the benefits of using TLS 1.3 and of using PSK importers may
prove sufficiently compelling that existing deployments choose to
enable this noncompliant configuration for a brief transition period
while new software (using TLS 1.3 and importers) is deployed.
Operators are advised to make any such transition period as short as
possible.
Paragraph (version A):
There is no known interference between the process for computing
Imported PSKs from an external PSK and the processing of existing
external PSKs used in (D)TLS 1.2 and below.  However, only limited
analysis has been done, which is an additional reason why
applications SHOULD provision separate PSKs for (D)TLS 1.3 and prior
versions, even when the importer interface is used in (D)TLS 1.3.
Paragraph (version B):
There are no known related outputs or security issues caused from the
process for computing Imported PSKs from an external PSK and the
processing of existing external PSKs used in (D)TLS 1.2 and below, as
noted in rollout.  However, only limited analysis has been done,
which is an additional reason why applications SHOULD provision
separate PSKs for (D)TLS 1.3 and prior versions, even when the
importer interface is used in (D)TLS 1.3.
Paragraph (version B):
Note also that ImportedIdentity.context is visible in cleartext on
the wire as part of the PSK identity.  Unless otherwise protected by
a mechanism such as TLS Encrypted ClientHello ECH, applications
SHOULD not put sensitive information in this field.