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

Sean Turner <> Thu, 25 February 2021 02:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 696F33A0CDD for <>; Wed, 24 Feb 2021 18:38:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 71dtQxgRY1qc for <>; Wed, 24 Feb 2021 18:38:04 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7DC143A0CDB for <>; Wed, 24 Feb 2021 18:38:04 -0800 (PST)
Received: by with SMTP id q85so4366813qke.8 for <>; Wed, 24 Feb 2021 18:38:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=AJ64CZ9gIxv9UmwcdY3iSrK9D2N4H0nncNbsUvm7OCg=; b=WzksSRoiGP7aO17gXtpXDNYbdD5N/FIdC1R+i0BJCEXNrRhHmn4YfGqqNT0CM4w/Ep pxP3yLZrctKoar7SLg9ZTnptz6GWgVdmrfsTL3Dzxtsw+g59ss2/FhSlSoDJMCWUgJmZ gOoovy24yAYFQmbqdQ+iGxa5COUfdHtVPkhig=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=AJ64CZ9gIxv9UmwcdY3iSrK9D2N4H0nncNbsUvm7OCg=; b=Afh2xg88uv5sDBqJLzlVrR/VqVLCgAKMjnRpRxpDS+02Rr3Vh1aDcWtk1pUO4rnmKq edKJrQlNganEttJylT7LbnMiCqw8jvrOKf5Ot7ykezI+LPpoj4WCmU87Q8ZMOyyppKep +z1qvqFcK7aeYcnb810f6hw7AYZqEKq0vHBrEiPR4dy1ymyh7HpRekCMeb8qLh6BaNrB q10dopAxa5iDvVB5cCjvYBxnabcZZjcvDiWNB5FNZ8Pkikiv7+YTmw6p5080wHPJc5qY 6+UmGhF5Fx6vOh6cWWu6tU8rQVml5TBQqdArGBFMUagKSwpRQBX6h/nPFo011buZlQXB OhYA==
X-Gm-Message-State: AOAM532dDY60QR+CPJWLkEnh7G07AjmTzxcva9TIHUfmAAzxhXW/M3vd WhhgxhqeDIfX4EJ+cdbCv7LRf1OsgvLaClgY
X-Google-Smtp-Source: ABdhPJzPcwipvlg63+JkLmrfwCNcg6QaBf+2wpfHrFbVr+CicAFCrNqXbQyQHtCuZLL/kboRmO1Inw==
X-Received: by 2002:a37:782:: with SMTP id 124mr920804qkh.165.1614220683086; Wed, 24 Feb 2021 18:38:03 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id y27sm2556586qtv.43.2021. for <> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Feb 2021 18:38:02 -0800 (PST)
From: Sean Turner <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Wed, 24 Feb 2021 21:38:01 -0500
References: <> <> <> <> <>
To: TLS List <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3654.
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: Thu, 25 Feb 2021 02:38:06 -0000

I have changed the tags on this draft to "WG Consenus: Waiting For Write-Up”. I will complete the Shepherd Write-Up, review it with the authors, and forward the I-D to our AD.


> On Feb 20, 2021, at 20:27, Russ Housley <> wrote:
> Sean and Joe:
> The revision to address Ben' comments has now been posted.
> I believe that all WGLC comments have been addressed.  I think this document is ready to go to the IESG.
> Russ
>> On Jan 22, 2021, at 3:27 PM, Russ Housley <> wrote:
>> 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?
>>> 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. 
>> 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