[TLS] Opsdir last call review of draft-ietf-tls-external-psk-guidance-03

Scott Bradner via Datatracker <noreply@ietf.org> Mon, 15 November 2021 19:05 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 873D93A08CF; Mon, 15 Nov 2021 11:05:40 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Scott Bradner via Datatracker <noreply@ietf.org>
To: ops-dir@ietf.org
Cc: draft-ietf-tls-external-psk-guidance.all@ietf.org, last-call@ietf.org, tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.39.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <163700314050.13967.3317725946581513113@ietfa.amsl.com>
Reply-To: Scott Bradner <sob@sobco.com>
Date: Mon, 15 Nov 2021 11:05:40 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/sCDj7V8AnFbUvvSnJ-Yi5O7SekI>
Subject: [TLS] Opsdir last call review of draft-ietf-tls-external-psk-guidance-03
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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, 15 Nov 2021 19:05:41 -0000

Reviewer: Scott Bradner
Review result: Has Nits

This is an OPS-DIR review of Guidance for External PSK Usage in TLS
<draft-ietf-tls-external-psk-guidance>.

As its title indicates, this ID provides guidance for the use of pre-shared
keys with TLS. Guidance documents are inherently useful to operations community
and this is no exception.

I found the document well written, slightly repetitive as Rich noted, but not
so much so as for it to be an issue for me.

A few notes though.

in section 4.2 the term PAKE is used without any definition – there is a
reference to a document but it seems to be that at least expanding the term in
this document would be useful.

the document uses the term SHOULD in a number of places.  (e.g. multiple places
in section 7 and one in section 8) – for what its worth – I am not a fan of the
use of this term unless the text also says when not doing what the SHOULD says
to do is OK – i.e. since SHOULD is a MUST with an escape clause – I think it is
useful to actually say what the escape clause is – i.e. explain why this is not
a MUST.  (also it does seem a bit funky to say (as section 7 does) “MUST
adhere” to requirements which are SHOULDs )