Re: [TLS] WGLC for "Guidance for External PSK Usage in TLS"

Russ Housley <> Fri, 18 December 2020 18:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 319ED3A0BBC for <>; Fri, 18 Dec 2020 10:55:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KCQs02_5cUaW for <>; Fri, 18 Dec 2020 10:55:44 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 949D63A00E0 for <>; Fri, 18 Dec 2020 10:55:44 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D944300ADC for <>; Fri, 18 Dec 2020 13:55:42 -0500 (EST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id 3TR0p99Bngwn for <>; Fri, 18 Dec 2020 13:55:40 -0500 (EST)
Received: from a860b60074bd.fios-router.home ( []) by (Postfix) with ESMTPSA id 82BA6300ADB; Fri, 18 Dec 2020 13:55:40 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Russ Housley <>
In-Reply-To: <>
Date: Fri, 18 Dec 2020 13:55:41 -0500
Cc: Joe Salowey <>, IETF TLS <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Jonathan Hammell <>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: <>
Subject: Re: [TLS] WGLC for "Guidance for External PSK Usage in TLS"
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 18 Dec 2020 18:55:47 -0000


Thanks for the review.

> Here are my comments on the draft.
> 1. Section 4 covers a lot of ground and is difficult to follow.  I
> suggest it be split into subsections (e.g. "4.1 PSKs Shared with
> Multiple Group Members" and "4.2 Weak Entropy PSKs") and move the
> attack description to an appendix.

I just reread it, and I think that the flow is okay.  It is about 2 pages.  That said, I can see it dividing into two clean subsections.  I'd prefer to leave the attack in the body of the first subsection.

> 2. In Section 4, para 2, the reference "As discussed in Section 6"
> refers to the use case of provisioning where multiple clients or
> servers share the same PSK, but Section 6 covers all use cases (and
> also provisioning). I suggest to create a couple more subsections for
> clarity and accurate referencing: "6.1 Use Cases for Pair-wise
> External PSKs" and "6.2 Use Cases for PSKs Shared with Multiple
> Entities", shifting the provisioning sections to 6.3 and 6.4.  Then
> the Section 4 citation can refer to Section 6.2.

I think your only concern is the granularity of the forward reference. I'm not sure most people would be confused.

> 3. Section 7, item 4 is missing a word.  s/This protects an attacker
> from/This protects against an attacker from/

Against the original text: s/protects/prevents/

> 4. Since there is no mitigation against revealing PSK identity, it is
> more accurate to rename Section 5 "Privacy Concerns".

How about "Privacy Considerations"?

> 5. Section 4, para starting with "Finally, in addition to these...":
> s/may negatively affects deployments/may negatively affect
> deployments/


> 6. Section 5, para 1: I don't think "oppress" is the right word to use
> here.  Perhaps, "suppress" would be better.


> 7. In Section 6, the last paragraph refers to Section 7 as the final
> sentence.  I assume this reference is for the recommendation to not
> share a PSK between more than one node, but it is not clear.  The
> previous sentence says do not share PSKs "even if other accommodations
> are made", but this conflicts with item 2 of Section 7 which says do
> not share PSKs "unless other accommodations are made".

How about:

   The exact provisioning process depends on the system requirements and
   threat model.  Whenever possible, avoid sharing a PSK between nodes;
   however, sharing a PSK among several node is sometimes unavoidable.
   When PSK sharing happens, other accommodations as needed as
   discussed in Section 7.

> 8. It is not clear why "client certificate authentication after
> PSK-based connection establishment", mentioned at the end of Section
> 6, is not a sufficient accommodation.  Should it be added to Section
> 7, item 2?


> 9. Section 7.1.2, first para, s/clash/collide

That is better.

> 10. Section 7.1.2 describes a possible concern regarding PSK identity
> collisions, but it does not provide a recommendation/mitigation for
> vendors or users.  What should the reader do with this information?

It means the application, not the stack need to handle the collision by following the advice in the document.

> 11. Section 6, item 2: the term "logical nodes" is not defined.

I suggest dropping "logical"