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

Commentary: , and . cc 
 Reviewer :    result : Has Nits OPS - DIR Review of : Importing External PSKs for TLS draft - ietf - tls - external - psk - importer-05 Note that   provided a useful review for GEN - ART , far beyond general questions .  's comments on Section 6 , Incremental Deployment , are relevant to operational considerations , which are the focus of this review . The draft provides a useful capability and considers possible issues stemming from interaction with ( D)TLS 1.2 . There are some implementations and other parties are interested . Nits : Intro : not expanded on first use PRF KDF 1 Terminology : one - too - many " and " in : ... Imported PSK ( IPSK ): A PSK derived from an EPSK , External Identity , optional context string , and target protocol and KDF . 
 Nits in the introduction are also listed in Roman 's review . section 3.1 should be updated . 
 Document : draft - ietf - tls - external - psk - importer-05 Reviewer :   Review Date : 2020 - 10 - 07 IETF LC End Date : 2020 - 10 - 15 IESG Telechat date : Summary : Ready with issues Issues : Introduction I think that " when possible " could easily be used as a loophole by a lazy implementer . ( " Impossible , because I 'd have to refactor my code . " ) Since presumably this rule is to avoid all risk of a " related output " cryptanalytic vulnerability , why weaken the RFC2119 definition of SHOULD ? The formal definition of SHOULD is stronger , with " the full implications must be understood and carefully weighed before choosing a different course . " So I suggest simply deleting " when possible " . Incremental Deployment I read this three times and I have to ask whether " TLS 1.2 " is really what you want in the penultimate line . Nits : 4.1 . External PSK Diversification ... As far as I can tell , [ QUIC ] does n't specify this , but draft - ietf - quic - tls does specify that QUICv1 uses  . So the phrasing is a bit misleading . Maybe : For example , TLS 1.3 [ RFC8446 ] uses 0x0304 , which will therefore also be used by QUICv1 [ QUIC - TLS ] . Are all the RFC2119 terms capitalised when required ? For example , there are lower case ' may ' and ' must ' in the last paragraph of section 4.1 ( External PSK Diversification ) . I could n't determine whether they were intended to be normative . 
 Section 1 . Editorial . Expand acronym on first use : -- s / TLS 1.2 PRF / TLS 1.2 Pseudorandom Function ( PRF)/ -- s / KDF / Key Derivation Function ( KDF)/ Section 1 . Editorial . Since the text says " ... this document specifies a PSK Importer interface ... for use in D(TLS 1.3 ) " perhaps the this scoping should also be upfront in the first sentence too : s / TLS 1.3 [ RFC8446 ] supports/(D)TLS 1.3 [ RFC8446][ID - DTLS]/ Section 4.1 . Editorial . Per " The list of ' targetkdf ' ... " , other parts of this text refer to elements of struct ImportIdentity with the notation " ImportedIdentity . " . Consider s / The list of " targetkdf " values / The list of ImportedIdentity.targetkdf values/ Section 4.1 . 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 [  ] . To the end of this normative guidance , I 'd recommend adding something to the effect of : " The details of this binding will be protocol specific and out of scope in this document " . Section 4.1 . Per " If no hash function is specified , SHA-256 MUST be used " -- Please provide a reference for SHA-256 ( per " ... If no hash function is specified , SHA-256 MUST be used " ) . -- It is likely worth saying that this is the equivalent of HKDFSHA256 ( i.e. , 0x0001 ) Section 4.1 . Per " EPSKs may be imported before the started of the connection ... " and " EPSKs may also be imported for early data use ... " should be these be a normative MAYs ? Section 4.1 . Per " Minimally , that means ALPN , QUIC ... must be provisioned alongside these EPSK " -- Please expand ALPN -- should this be a normative MUST ? Section 9 . Per the columns in the registry : -- Is there a reason why there is n't a Reference column in the registry to capture which specification describes the particular KDF ? I think it needs one to eliminate guesswork from the label in " KDF Description " to an algorithm . -- Was a Recommended column ( and the associated processed for populating it like a few of the other TLS registries ) discussed / considered ? Section 9 . While it is implied by the label , the text does n't explicitly say what HKDFSHA256 and SHA384 are ( per previous comment about needing a reference ) .
Paragraph (version A):
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.  While there is no known way in which the same
external PSK might produce related output in TLS 1.3 and prior
versions, only limited analysis has been done.  Applications SHOULD
provision separate PSKs for TLS 1.3 and prior versions when possible.
Paragraph (version A):
To mitigate against any interference, this document specifies a PSK
Importer interface by which external PSKs may be imported and
subsequently bound to a specific KDF and hash function for use in
(D)TLS 1.3.  In particular, it describes a mechanism for
differentiating external PSKs by the target KDF, (D)TLS protocol
version, and an optional context string.  This process yields a set
of candidate PSKs, each of which are bound to a target KDF and
protocol, that are separate from those used in (D)TLS 1.2 and prior
versions.  This expands what would normally have been a single PSK
and identity into a set of PSKs and identities.
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 pseudorandom function (PRF).  While there is no known
way in which the same external PSK might produce related output in
TLS 1.3 and prior versions, only limited analysis has been done.
Applications SHOULD provision separate PSKs for TLS 1.3 and prior
versions.
Paragraph (version B):
To mitigate against any interference, this document specifies a PSK
Importer interface by which external PSKs may be imported and
subsequently bound to a specific key derivation function (KDF) and
hash function for use in TLS 1.3 RFC8446 and DTLS 1.3 DTLS13.  In
particular, it describes a mechanism for differentiating external
PSKs by the target KDF, (D)TLS protocol version, and an optional
context string.  This process yields a set of candidate PSKs, each of
which are bound to a target KDF and protocol, that are separate from
those used in (D)TLS 1.2 and prior versions.  This expands what would
normally have been a single PSK and identity into a set of PSKs and
identities.
Paragraph (version A):
Imported PSK (IPSK): A PSK derived from an EPSK, External
Identity, optional context string, and target protocol and KDF.
Paragraph (version B):
Imported PSK (IPSK): A PSK derived from an EPSK, External
Identity, optional context string, target protocol, and target
KDF.
Paragraph (version A):
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 B):
The list of ImportedIdentity.target_kdf values is maintained by IANA
as described in IANA.  External PSKs MUST NOT be imported for (D)TLS
PSKs for TLS 1.3 and non-imported PSKs for earlier versions co-exist
for incremental deployment.
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.
Paragraph (version A):
ImportedIdentity.target_protocol MUST be the (D)TLS protocol version
for which the PSK is being imported.  For example, TLS 1.3 RFC8446
and QUICv1 QUIC use 0x0304.  Note that this means future versions of
TLS will increase the number of PSKs derived from an external PSK.
Paragraph (version B):
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.target_protocol MUST be the (D)TLS protocol version
for which the PSK is being imported.  For example, TLS 1.3 RFC8446
uses 0x0304, which will therefore also be used by QUICv1 QUIC.  Note
that this means future versions of TLS will increase the number of
PSKs derived from an external PSK.
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 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 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 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 ALPN, QUIC transport parameters (if used for QUIC), etc.,
must be provisioned alongside these EPSKs.
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 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 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.
Paragraph (version B):
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 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 when possible, even when the importer interface is used in
(D)TLS 1.3.
Paragraph (version B):
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.