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

From: Joseph Salowey <[email-masked]>
Date: Thu, 3 Dec 2020 16:51:18 -0800

This email starts the working group last call for "Guidance for External
PSK Usage in TLS", located here:

   https://tools.ietf.org/html/draft-ietf-tls-external-psk-guidance-01

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:

   https://github.com/tlswg/external-psk-design-team

Thanks,
Joe and Sean

---

From: Jonathan Hammell <[email-masked]>
Date: Wed, 16 Dec 2020 14:14:07 -0500

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

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.

Jonathan

On Thu, Dec 3, 2020 at 7:52 PM Joseph Salowey <[email-masked]> 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.
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Russ Housley <[email-masked]>
Date: Fri, 18 Dec 2020 13:55:41 -0500

Jonathan:

Thanks for the review.

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

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

> from/This protects against an attacker from/

Against the original text: s/protects/prevents/

> more accurate to rename Section 5 "Privacy Concerns".

How about "Privacy Considerations"?

> s/may negatively affects deployments/may negatively affect

Agreed.

> here.  Perhaps, "suppress" would be better.

Agreed.

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

> 6, is not a sufficient accommodation.  Should it be added to Section

Agreed,

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

That is better.

> 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

---

From: Jonathan Hammell <[email-masked]>
Date: Mon, 21 Dec 2020 09:30:11 -0500

Hi Russ,

> 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 sub…

Okay.  Just an editorial suggestion.

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

> Against the original text: s/protects/prevents/

That is better than my suggestion.  Thanks.

> How about "Privacy Considerations"?

Even better.

>    When PSK sharing happens, other accommodations as needed as

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.

Thanks,
Jonathan

---

From: Russ Housley <[email-masked]>
Date: Mon, 21 Dec 2020 11:50:04 -0500

I made a PR with these changes.

Russ

> On Dec 21, 2020, at 9:30 AM, Jonathan Hammell <[email-masked]> wrote:
> 
> Hi Russ,
>