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

Russ Housley <housley@vigilsec.com> Mon, 21 December 2020 16:50 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 2B2503A1240 for <tls@ietfa.amsl.com>; Mon, 21 Dec 2020 08:50:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 kmELsCIZkFi7 for <tls@ietfa.amsl.com>; Mon, 21 Dec 2020 08:50:07 -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 8B2F73A1091 for <tls@ietf.org>; Mon, 21 Dec 2020 08:50:07 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1A611300BC5 for <tls@ietf.org>; Mon, 21 Dec 2020 11:50:05 -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 nZTHpCS1F4jT for <tls@ietf.org>; Mon, 21 Dec 2020 11:50:02 -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 9B0C1300ADB; Mon, 21 Dec 2020 11:50:02 -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: <CALhKWghLGhHhy2LjAmygO-naEpB-J0q4pknVhzQBrhoY6cpP7w@mail.gmail.com>
Date: Mon, 21 Dec 2020 11:50:04 -0500
Cc: Joe Salowey <joe@salowey.net>, IETF TLS <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F0D42188-EB76-4C69-B806-C9F7B6A7D764@vigilsec.com>
References: <CAOgPGoADZ=0-VnpHmU4GO996DuFefyfb4ia7wAjZ7h-bZkyDzQ@mail.gmail.com> <CALhKWghvD3yXTj5OcV9ENPwX=FdfJhUVHP3sCCgtq8bhxMYV0A@mail.gmail.com> <9A762E08-9935-4C8B-ABBC-7A53BD5CB68A@vigilsec.com> <CALhKWghLGhHhy2LjAmygO-naEpB-J0q4pknVhzQBrhoY6cpP7w@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/Wsurn-mDwGVgOddsFtbTSz3cygY>
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: Mon, 21 Dec 2020 16:50:09 -0000

I made a PR with these changes.

Russ


> On Dec 21, 2020, at 9:30 AM, Jonathan Hammell <jfhamme.cccs@gmail.com> wrote:
> 
> Hi Russ,
> 
> On Fri, Dec 18, 2020 at 1:55 PM Russ Housley <housley@vigilsec.com> wrote:
>>> 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.
> 
> Okay.  Just an editorial suggestion.
> 
>>> 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.
> 
> Yes, it is the granularity of the reference.  If you think it is okay,
> then leave it as is.
> 
>>> 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/
> 
> That is better than my suggestion.  Thanks.
> 
>>> 4. Since there is no mitigation against revealing PSK identity, it is
>>> more accurate to rename Section 5 "Privacy Concerns".
>> 
>> How about "Privacy Considerations"?
> 
> Even better.
> 
>>> 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.
> 
> That is better, except that I think you meant "are needed as
> discussed" near the end.  But I wonder if that should be written in
> requirements language, such as "other accommodations SHOULD be used as
> discussed in Section 7."  A SHOULD is maybe not as strong as "are
> needed", but I'm not sure if a MUST will be acceptable here.
> 
>>> 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"
>> 
> 
> Thanks,
> Jonathan