[secdir] 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: secdir@ietf.org
Delivered-To: secdir@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/secdir/L2SefzYa92HIxM7Fqnlw0Pbz1l0>
Subject: [secdir] Secdir last call review of draft-ietf-tls-external-psk-guidance-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-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.
- [secdir] Secdir last call review of draft-ietf-tl… Rich Salz via Datatracker
- Re: [secdir] Secdir last call review of draft-iet… Sean Turner