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

Russ Housley <housley@vigilsec.com> Fri, 18 December 2020 18:55 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 319ED3A0BBC for <tls@ietfa.amsl.com>; Fri, 18 Dec 2020 10:55:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCQs02_5cUaW for <tls@ietfa.amsl.com>; Fri, 18 Dec 2020 10:55:44 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 949D63A00E0 for <tls@ietf.org>; Fri, 18 Dec 2020 10:55:44 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2D944300ADC for <tls@ietf.org>; Fri, 18 Dec 2020 13:55:42 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3TR0p99Bngwn for <tls@ietf.org>; Fri, 18 Dec 2020 13:55:40 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (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 <housley@vigilsec.com>
In-Reply-To: <CALhKWghvD3yXTj5OcV9ENPwX=FdfJhUVHP3sCCgtq8bhxMYV0A@mail.gmail.com>
Date: Fri, 18 Dec 2020 13:55:41 -0500
Cc: Joe Salowey <joe@salowey.net>, IETF TLS <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9A762E08-9935-4C8B-ABBC-7A53BD5CB68A@vigilsec.com>
References: <CAOgPGoADZ=0-VnpHmU4GO996DuFefyfb4ia7wAjZ7h-bZkyDzQ@mail.gmail.com> <CALhKWghvD3yXTj5OcV9ENPwX=FdfJhUVHP3sCCgtq8bhxMYV0A@mail.gmail.com>
To: Jonathan Hammell <jfhamme.cccs@gmail.com>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ryj82NBhKYsO3hSGSdrlEM-aD4g>
Subject: Re: [TLS] WGLC for "Guidance for External PSK Usage in TLS"
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Dec 2020 18:55:47 -0000

Jonathan:

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/

Agreed.

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

Agreed.

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

Agreed,

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

Russ