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

Rich Salz via Datatracker <noreply@ietf.org> Mon, 15 November 2021 18:41 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 EA99B3A07CC; Mon, 15 Nov 2021 10:41:02 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Rich Salz via Datatracker <noreply@ietf.org>
To: secdir@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: <163700166290.13984.13464784184351879479@ietfa.amsl.com>
Reply-To: Rich Salz <rsalz@akamai.com>
Date: Mon, 15 Nov 2021 10:41:02 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/-GQFt2AC-Ysv1SUB_6Y97u8SyNQ>
Subject: [TLS] Secdir 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 18:41:03 -0000

Reviewer: Rich Salz
Review result: Has Nits

I'm the SECDIR reviewer for this document. This is a TLS WG draft, so everyone
reading this should know what that means. If not, ask. :)

As the opening sentence says, "This document provides usage guidance for
external Pre-Shared Keys (PSKs) in Transport Layer Security (TLS) 1.3 as
defined in RFC 8446."

PSKs are useful and important for those who do not wish to deploy a PKI or for
whom symmetric trust is useful. I like section 4.1 which goes into detail about
the problems with sharing keys among more than two parties. Section 6 is a good
summary of use-cases with references. These sections should prove as valuable
as section 7, which is presumably the heart of the document.

Section 7.1 is not common for an IETF RFC, and shows evidence that the authors
have some scars from experiments or deployments.  It is nice to see.

Section 8 says "The unique identifier can, for example, be one of its MAC
addresses..."    I thought we are moving away from that and I would prefer to
see an explicit justification of why this is okay. I think this is a nit-level
issue, and the only one I found.

I also do suggest, however, that the draft be sent to the UTA working group and
ask for comments from them as they're more application-focused like this
document it.