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

Commentary: Addresses . cc 
 The document says : Aside from this statement needing update in light of the changes to the binder label , the core statement here is n't expanded upon . The document needs to very clearly say that the PSK ID that is sent in the psk extension is literally the serialized content of . 
 Fixed in .
Paragraph (version B):
identities.
Paragraph (version A):
Key importers mirror the concept of key exporters in TLS in that they
diversify a key based on some contextual information before use in a
connection.  In contrast to key exporters, wherein differentiation is
done via an explicit label and context string, the key importer
defined herein uses an optional context string along with a target
protocol and KDF identifier to differentiate an external PSK into one
or more PSKs for use.
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.  Endpoints may
incrementally deploy PSK importer support by offering non-imported
keys for TLS versions prior to TLS 1.3.  Non-imported and imported
PSKs are distinct since their identities are different on the wire.
See rollout for more details.
Paragraph (version B):
Key importers mirror the concept of key exporters in TLS in that they
diversify a key based on some contextual information before use in a
connection.  In contrast to key exporters, wherein differentiation is
done via an explicit label and context string, the key importer
defined herein diversifies external one PSK into one or more PSKs for
use via a target protocol, KDF identifier, and optional context
string.  Additionally, the resulting PSK binder key is modified with
a new derivation label to prevent confusion with non-imported PSKs.
Paragraph (version B):
Imported keys do not require negotiation for use, as a client and
server will not agree upon identities if not imported correctly.
Endpoints may incrementally deploy PSK importer support by offering
non-imported keys for TLS versions prior to TLS 1.3.  Non-imported
and imported PSKs are distinct since their identities are different
on the wire.  See rollout for more details.
Paragraph (version A):
This new label differentiates non-imported and imported external
PSKs.  Specifically, a client and server will negotiate use of an
external PSK if and only if (a) both endpoints import the PSK or (b)
neither endpoint imports the PSK.  The "binder_key" is a leaf key.
Therefore, changing its computation doesn't affect any other key.
Paragraph (version B):
A key importer diversifies an input EPSK into one or more PSKs
advertised on the wire via a target protocol, KDF identifier, and
optional context string.  Additionally, the resulting PSK binder key
is modified with a new derivation label to prevent confusion with
non-imported PSKs.  This section describes the diversification
mechanism and binder key computation change.
Paragraph (version A):
The list of "target_kdf" values is maintained by IANA as described in
IANA.  External PSKs MUST NOT be imported for versions of (D)TLS 1.2
or prior versions.  See rollout for discussion on how imported PSKs
for TLS 1.3 and non-imported PSKs for earlier versions co-exist for
incremental deployment.
Paragraph (version B):
The list of "target_kdf" values is maintained by IANA as described in
IANA.  External PSKs MUST NOT be imported for (D)TLS 1.2 or prior
versions.  See rollout for discussion on how imported PSKs for TLS
incremental deployment.
Paragraph (version A):
The identity of 'ipskx' as sent on the wire is ImportedIdentity.
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.
Paragraph (version B):
This new label differentiates non-imported and imported external
PSKs.  Specifically, a client and server will negotiate use of an
external PSK if and only if (a) both endpoints import the PSK or (b)
neither endpoint imports the PSK.  As "binder_key" is a leaf key,
changing its computation does not affect any other key.