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

Jonathan Hammell <> Wed, 16 December 2020 19:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9DA903A0B32 for <>; Wed, 16 Dec 2020 11:14:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lSE9J6DC6WKo for <>; Wed, 16 Dec 2020 11:14:19 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E08DA3A0B2D for <>; Wed, 16 Dec 2020 11:14:18 -0800 (PST)
Received: by with SMTP id p126so28791683oif.7 for <>; Wed, 16 Dec 2020 11:14:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9CjNrp02qxu5fZEpKjD5RVKQ/C6H5vZ/zCdxMhDgWD4=; b=bT9GV1r/r7xUC8hCsXGLTl/YG0+20B+oHr2dmtPZKqOqpeKQYdORYDPXXmLHmgqNNg vo/KfRrWPVPvrN3rMLCFZXVM0jLZD28CwMbgUaZKiAwZxAz2NamTA7Ope3xWA/OuLg+E ze6/v3syzMgmlY5QaX1pElV+2zYVTlhq4yEXJgGXFneM6Sw8HJP3tt5KOPUlGOIK3YJB qh4VzgucBOA9xmaDLZIjM1v2/kfz2ZGycLh45bSELALAbfyj4Gjkydf+46iupam3k22V b2ZAUFHb06JrEbbLKnhWckDXBf50VxRGBiHsN61tnq42liLM1auyHNz3RaFmQEJLa2bK UPeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9CjNrp02qxu5fZEpKjD5RVKQ/C6H5vZ/zCdxMhDgWD4=; b=MyOMV0jlkSH4VNxnsHmfDzw3B9hWJxoAiCowW3fjvBsSM7AbukXN1RbdKu2uPH1Shg YMWh2lQXfda1K4mYPWlFFfIO3QsuU1eZxtfhzV132J9bsULDyPxU4rcxXyS/IdggTd1N D72f5S9I3pP+5bSw41M3lCrsAjSVZN5an2kaFTC1ixGnZXKz594a9GoQfzVG1Jb/y/K7 zFoW515ohMFlVQenHaFXWJz6QKxP2PeDmFaCwTetGcNmxqENkGPcQ3rUZvq2Oz54OYxC +gaMO2Z/hfkAT17ZxOwWKB7/c7/sz1EFMCrtxk9QVLNA44H55WBTbXLBuDBX74ce+qxd x5VA==
X-Gm-Message-State: AOAM533m+OOOss39Zw3ou58+1Mxr28/MNIoK60Lnf+HaxYBGDCl6+vVS nZPX9Vv2Jdib+FSrlDFPMZIhmN4tekVA+D+TDPJwVTblizDUDg==
X-Google-Smtp-Source: ABdhPJx79MHJIDr/I5qv6cLIA1s2d8omZvUozwnN994c95oqY50p8AXVI67UWlO3gVHJ2/SOLlxwnLYFm8BiVfhiMis=
X-Received: by 2002:aca:dc54:: with SMTP id t81mr2762531oig.101.1608146058302; Wed, 16 Dec 2020 11:14:18 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Jonathan Hammell <>
Date: Wed, 16 Dec 2020 14:14:07 -0500
Message-ID: <>
To: Joseph Salowey <>
Cc: "<>" <>
Content-Type: text/plain; charset="UTF-8"
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: Wed, 16 Dec 2020 19:14:21 -0000

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.

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.

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

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

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

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

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

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?

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


On Thu, Dec 3, 2020 at 7:52 PM Joseph Salowey <> wrote:
> This email starts the working group last call for "Guidance for External PSK Usage in TLS", located here:
> Please review the document and send your comments to the list by December 18, 2020.
> Note the the GitHub repository for this draft can be found here:
> Thanks,
> Joe and Sean
> _______________________________________________
> TLS mailing list