[TLS] AD review of draft-ietf-tls-external-psk-guidance-02

[Benjamin Kaduk <[e-mail]>]

Hi all,

In general the content here is good, though there's a few things in
sections 4 and 4.1 that I'm not entirely sure about, and we might stand
to be a bit more clear about to what extent TLS pre 1.3 is in scope (we
do talk about it in some places, but the declared scope is only (D)TLS
1.3 plus cTLS (which is a 1.3 variant).

I made a PR with some basically editorial suggestions:
https://github.com/tlswg/external-psk-design-team/pull/68

It seems like we might want to have a sentence or two in the
introduction or terminology section defining what we mean by "external
PSK" (e.g., "a symmetric secret key provided to the TLS library as an
external input").  I think the first mention of "provisioned
out-of-band" is currently not until §6...

Should we have a note that when we write "TLS 1.3" it applies to DTLS
and cTLS as well?

Section 1

The abstract notes that this document "lists the privacy and security
properties that are not provided by TLS when external PSKs are used",
but I don't see much analogous to that in the Introduction.  (The
overlap between Abstract and Introduction is a bit higher than I prefer,
but I don't have any suggested improvements.)


Section 4

   External PSK authentication in TLS allows endpoints to authenticate
   connections using previously established keys.  These keys do not
   provide protection of endpoint identities (see Section 5), nor do

We might want to disambiguate between "authentication of endpoint
identities" and "confidentiality protection for endpoint identities",
since just "protection" could read as either one.  (Also applies to the
following sentence.)

   they provide non-repudiation (one endpoint in a connection can deny
   the conversation).  Protection of endpoint identities and protection
   against an endpoint denying the conversation are possible when a
   fresh TLS handshake is performed.

I don't understand the last sentence -- is this a "fresh TLS handshake"
using the same external PSK that we just said doesn't provide these
things?  Are we equating "fresh handshake" with "uses certificates"?

Section 4.1

   2.  If PSK with DH is used, then compromise of a group member that
       actively completes connections with other group members can read
       (and modify) traffic.

I can't parse this sentence: "If <X>, then compromise of <Y>" needs
another clause, like "allows the attacker to <Z>", but currently the
sentence parses with <Y> basically consuming the rest of the sentence.

(Also, does "actively complete" mean to receive, initiate, or both?)

   4.  If a group member is compromised, then the attacker can perform
       all of the above attacks.

I'm not sure I understand how this item adds value, since (2) and (3)
explicitly assume "compromise of a group member" and for the case of (1)
compromising a group member naturally satisfies "any group member
can...".

   Additionally, a malicious non-member can reroute handshakes between
   honest group members to connect them in unintended ways, as described
   below.  Note that this class of attack is not possible if each member
   uses the SNI extension [RFC6066] and terminates the connection on
   mismatch.  See [Selfie] for details.

SNI only authenticates the server identity; it seems that if (e.g.) A
and B both initiate connections to C at the same time, the attacker can
make C think that A and B's connections/identities are swapped.  (I
don't remember if [Selfie] directly touches on this attack or not.)

   This attack violates the peer authentication property, and if "C"
   supports a weaker set of cipher suites than "B", this attack also
   violates the downgrade protection property.  [...]

I think we might want to say a little more about how this violdates the
downgrade protection property (or "fails to provide downgrade
protection", since violating a property is a somewhat unusual phrasing).
Most of the instances of the word "downgrade" in RFC 8446 rever to (TLS)
version downgrade, with essentially only the definition of "downgrade
protection" in Appendix E.1 mentioning arbitrary "cryptographic
parameters" that should be the same on both peers as in the absence of
an attack.  But in this setup we have three entities involved, and it's
not clear to which pair we should apply the test -- if A was intending
to talk to C, it would get the same parameters it actually did.  And the
attacker doesn't really affect the negotiation per se -- it can't force
a weaker cipher just because C has it enabled.  A has to offer it, and
it has to be the one that C actually picks.  So the negotiated
ciphersuite would only be different if B and C have different
most-preferred ciphers from A's list, which is perhaps a bit harder to
achieve in practice than just "C supports weaker ciphers".

Section 6.1

   *  Some secrets may be baked into or hardware or software device
      components.  Moreover, when this is done at manufacturing time,
      secrets may be printed on labels or included in a Bill of
      Materials for ease of scanning or import.

It seems like we should comment on the risks that printing the baked-in
PSK on a label or in a BoM incur for the security of the system of as
whole.

Section 7

   2.  Unless other accommodations are made, each PSK MUST be restricted

We probably want a few more words about what the accommodations are
for (e.g., "to mitigate the risks of group-shared PSK usage" or "to
provide explicit node identification").

Section 8

This one-paragraph security considerations feels quite short for a
document of this nature.  Perhaps we want a note about "security
considerations are discussed throughout this memo" (plus transition
phrase) as well as the current content?

I might also consider an introductory sentence to reiterate that the
biggest concerns specific to PSK relate to the determination of the
identities of the communicating parties and the increase in risk as the
PSK is shared more broadly (which seems to be a summary of the remaining
content of the section).

Section 10.1

It seems that we only reference DTLS 1.3 for our scope of applicability,
which doesn't necessarily make it a normative reference.  (cTLS is
referenced in the same way but is classified as informative already.)

NITS

Section 5

   PSK privacy properties are orthogonal to security properties
   described in Section 4.  Traditionally, TLS does little to keep PSK
   identity information private.  For example, an adversary learns

IIRC, "traditionally" is on the NIST word list and will get flagged by
Lars' review script and the RFC Editor.  If you change it now, that will
avoid getting pestered later (but changing it is not a hard
requirement).

Section 6.1

   *  Many industrial protocols assume that PSKs are distributed and
      assigned manually via one of the following approaches: typing the
      PSK into the devices, or via web server masks (using a Trust On

I don't think I know what a "web server mask" is.

Section 7

   3.  Nodes using TLS 1.3 SHOULD use external PSK importers
       [I-D.ietf-tls-external-psk-importer] when configuring PSKs for a
       client-server pair.  [...]

My read of the introduction is that we only provide guidance for (D)TLS
1.3 and cTLS, which means that importers will always be available.  Do
we need to specify "using TLS 1.3" here?

Section 7.1.2

   stack's internal session resumption cache.  This means that if a PSK
   identity collision occurs, the application will be given precedence
   over how to handle the PSK.

I don't think that the TLS stack will give an indication to the callback
that there was a collision, so "precedence over how to handle" may not
be quite accurate.  Maybe something like "the application's external PSK
usage will typically take precedence over the internal session
resumption path"?

Thanks,

Ben