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

From: Joseph Salowey <[email-masked]>
Date: Sat, 16 Jan 2021 12:29:16 -0800

Hello Working Group,

We've only had one review in response to the last call so far,  I'd like to
see a few more reviews of this document before moving it forward.  Are
there any volunteers who can commit to a review in the near future?

Thanks,

Joe

On Thu, Dec 3, 2020 at 4:51 PM Joseph Salowey <[email-masked]> wrote:

> 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: Ben Smyth <[email-masked]>
Date: Tue, 19 Jan 2021 11:27:00 +0100

Dear Joe,

On Sat, 16 Jan 2021 at 21:29, Joseph Salowey <[email-masked]> wrote:

> We've only had one review in response to the last call so far,  I'd like
> to see a few more reviews of this document before moving it forward.  Are

I've reviewed and have only a handful of minor comments.

Section 1, opening: Password and key comparison seems rather weak, unless
low-entropy PSKs are used. If low-entropy PSKs are a focus, then perhaps
make this clearer, which will simultaneously strengthen the comparison.

Section 4, "These keys do not provide protection of endpoint identities
(see Section 5), nor do they provide non-repudiation (one endpoint in a
connection can deny the conversation)": Perhaps relate to other modes of
TLS which do provide such protection.

Section 4, "If this assumption is violated": The assumption has two
aspects, namely, "each PSK is known to exactly one client and one server"
and "these never switch roles." The following paragraph explains what
happens if each PSK is known to more than one client, server, or both. But
what if roles are switched? Whilst maintaining the former aspect of the
assumption.

Section 4, "then the security properties of TLS are severely weakened":
Perhaps add "as explained below" or similar.

Best regards,

Ben

---

From: Russ Housley <[email-masked]>
Date: Fri, 22 Jan 2021 15:27:06 -0500

Ben:

Thanks for you review and comments.

> We've only had one review in response to the last call so far,  I'd like to see a few more reviews of this document before moving it forward.  Are there any volunteers who can commit to a review in the near future?
> 
> Section 1, opening: Password and key comparison seems rather weak, unless low-entropy PSKs are used. If low-entropy PSKs are a focus, then perhaps make this clearer, which will simultaneously strengthen the comparison. 

There is guidance on many other aspects of security as well.  Maybe this comparison is setting inappropriate expectations.  Maybe the first paragraph should avoid the comparison altogether.  I suggest:

   This document provides guidance on the use of external Pre-Shared
   Keys (PSKs) in Transport Layer Security (TLS) version 1.3 [RFC8446].
   This document lists TLS security properties provided by PSKs under
   certain assumptions and demonstrates how violations of these
   assumptions lead to attacks.  This document also discusses PSK use
   cases, provisioning processes, and TLS stack implementation support
   in the context of these assumptions.  It provides advice for
   applications in various use cases to help meet these assumptions.

> Section 4, "These keys do not provide protection of endpoint identities (see Section 5), nor do they provide non-repudiation (one endpoint in a connection can deny the conversation)": Perhaps relate to other modes of TLS which do provide such protection.

I suggest adding:

   Protection of endpoint identities and protection against an endpoint denying
   the conversation are possible when a fresh TLS handshake is performed.

> Section 4, "If this assumption is violated": The assumption has two aspects, namely, "each PSK is known to exactly one client and one server" and "these never switch roles." The following paragraph explains what happens if each PSK is known to more than one client, server, or both. But what if roles are switched? Whilst maintaining the former aspect of the assumption.

The only cases where that I have come up with where it is possible for the client and server to swap roles (like TLS between to mail servers) do not actually cause any trouble.  If a browser and a web server got confused about their roles, it could be a problem, but that does not seem likely to happen either.  Does anyone have a suggestion here?

> Section 4, "then the security properties of TLS are severely weakened": Perhaps add "as explained below" or similar.

Good idea.  Added.

Russ

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 26 Jan 2021 18:56:25 +0000

Sorry for being so late on this.

I think this is a really good document. It covers the risks, trade-offs, and provides excellent advice.  It is also quite readable – good job by the authors!

   https://tools.ietf.org/html/draft-ietf-tls-external-psk-guidance-01<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-tls-external-psk-guidance-01__;!!GjvTz_vk!HxrpY1J5SknhBQxGSz4cq9Eg6AjH3pcd3Amt-8Gli7naclkLOjOIi3OGNYUi$>

Please review the document and send your comments to the list by December 18, 2020.