[art] Artart telechat review of draft-ietf-tls-external-psk-importer-07

[Darrel Miller via Datatracker <[e-mail]>]

Reviewer: Darrel Miller
Review result: Ready with Nits

I have reviewed draft-ietf-tls-external-psk-importer-07 but must qualify my
review with the fact that I have minimal background in this technical area.

Section 1:

The paragraph states that in TLS 1.3 "each PSK only be used with a single hash 
function" and goes on to say in TLS 1.2 "a PSK may be used  with any hash
algorithm".  The first seems to suggest a constraint on how many times a PSK
can be used, whereas the second appears to be talking about the set of hash
algorithms that a PSK can be used with.  This could simply be my ignorance, but
I got hung up on it.  Would it be correct to replace "any" with "many"?

"Applications SHOULD provision separate PSKs for TLS 1.3 and prior versions" 
Is this saying "Applications SHOULD provision PSKs for TLS 1.3 separately from
PSKs for prior versions"?  Or is it saying "Applications SHOULD provision
separate PSKs for each TLS version"?

If I have understood the goal of this document, I found the use of phrases like
"differentiating external PSKs" and "External PSK Diversification" misleading.
The process seems to be taking external PSKs and deriving new PSKs to avoid the
problem of PSK reuse.  If that is the case, then the phrase

"In particular, it describes a mechanism for differentiating external PSKs by
the target KDF, (D)TLS protocol version, and an optional    context string."

would be clearer to me as something like

"In particular, it describes a mechanism for importing PSKs derived from
external PSKs by including the target KDF, (D)TLS protocol version, and an
optional  context string to ensure uniqueness."

I must reiterate that these technical terms are largely opaque to me, so I may
be missing many realities.

Section 3:
nit: "Each of these derived PSKs are bound a target protocol, KDF identifier,
and optional context string."  Should this be "bound to"?

"Through this interface, importing external PSKs with different identities
yields  distinct PSK binder keys."  This raises the question for me, is it
important that the imported PSK be unique, or that the PSK binder key be
unique?  It is mentioned that the derivation creates a set of PSKs and
Identities.  The notion of "Imported Identity" is described in the terminology
but "PSK binder key" is not. Are these the same thing?

"Non-imported and imported PSKs are distinct since their identities are
different on the wire."  Is the "on the wire" qualification important? It
causes me to ask the question, does the identity of a PSK change when it goes
on the wire? Are the Identities not different when not on the wire?

Section: 3.1  This was very helpful for me.  For me it would have been easier
to read the overview if the terminology had come first and was used there.

Section: 4.1   "External PSKs MUST NOT be imported for (D)TLS 1.2 or prior
versions."  Is the "External" qualifier necessary?  The next sentence uses the
phrase "non-imported PSKs" and I find myself asking if there is a significance
to that distinction.  I think there isn't, but from a comprehension perspective
it is extra terminology to process.

In the 6th paragraph it is mentioned that the Imported Identity is stored in a
PSK extension.  That was a helpful concrete implementation detail that would
have been useful to know in the first paragraph.

"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"

For the statement "If no hash function is specified", are we talking about the
hash function "associated with the EPSK" or the one in
"ImportedIdentity.target.kdf". This paragraph is trying to talk about both at
the same time and I am struggling to unravel it.

Section 6:  The first paragraph seems to be largely repetitive of what was said
in Section 4.1 paragraph 2 and re-addressed in section 7.  While it might be
good to restate the constraint, the words used are different and I found myself
trying to figure out if it was adding any additional restrictions that were not
previously stated.

I think my primary feedback on this document relates to the constraint of not
re-using PSKs.  It feels like in an attempt to emphasize the importance, the
point has been made numerous times in different ways with different terms and I
think in this case, more clarity could be achieved with less words. e.g.

"Applications SHOULD provision separate PSKs for TLS 1.3 and prior versions"
"Endpoints which import external keys MUST NOT use the keys that are  input to
the import process for any purpose other than the importer" "MUST NOT use the
derived keys for any purpose other than TLS  PSKs" "external PSK fed to the
importer process MUST  be associated with at most one hash function" "External
PSKs MUST NOT be imported for  (D)TLS 1.2 or prior versions" "this document
requires that an EPSK is only ever used as an EPSK and not for any other
purpose" "this requirement disallows direct use of the EPSK as a PSK in TLS
1.2" "avoid PSK re-use across KDFs while properly authenticating endpoints"
"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"

It is highly likely that some of these distinctions are important, especially
because some of these are SHOULDs and some are MUSTs. However, my guess is that
some of these phrases are saying the same thing in different words and for me
they are obscuring the important distinctions.  That could simply be my lack of
domain knowledge.

I appreciate the effort that folks put into topics such as these to ensure all
of us can use the Internet securely.  Hopefully some of my feedback will be
useful.