Skip to main content

Last Call Review of draft-ietf-tls-external-psk-guidance-03
review-ietf-tls-external-psk-guidance-03-secdir-lc-salz-2021-11-15-00

Request Review of draft-ietf-tls-external-psk-guidance
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2021-11-19
Requested 2021-10-29
Authors Russ Housley , Jonathan Hoyland , Mohit Sethi , Christopher A. Wood
Draft last updated 2021-11-15
Completed reviews Opsdir Last Call review of -03 by Scott O. Bradner (diff)
Artart Last Call review of -03 by Martin Thomson (diff)
Secdir Last Call review of -03 by Rich Salz (diff)
Secdir Telechat review of -04 by Rich Salz (diff)
Assignment Reviewer Rich Salz
State Completed
Review review-ietf-tls-external-psk-guidance-03-secdir-lc-salz-2021-11-15
Posted at https://mailarchive.ietf.org/arch/msg/secdir/L2SefzYa92HIxM7Fqnlw0Pbz1l0
Reviewed revision 03 (document currently at 06)
Result Has Nits
Completed 2021-11-15
review-ietf-tls-external-psk-guidance-03-secdir-lc-salz-2021-11-15-00
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.