Skip to main content

IETF Last Call Review of draft-ietf-tls-8773bis-09
review-ietf-tls-8773bis-09-secdir-lc-weis-2025-07-28-00

Request Review of draft-ietf-tls-8773bis
Requested revision No specific revision (document currently at 13)
Type IETF Last Call Review
Team Security Area Directorate (secdir)
Deadline 2025-07-28
Requested 2025-07-07
Authors Russ Housley
I-D last updated 2026-04-08 (Latest revision 2025-09-05)
Completed reviews Genart IETF Last Call review of -09 by Christer Holmberg (diff)
Secdir IETF Last Call review of -09 by Brian Weis (diff)
Assignment Reviewer Brian Weis
State Completed
Request IETF Last Call review on draft-ietf-tls-8773bis by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/4yVAAeNhb_H5vIaglWPlWCveGUc
Reviewed revision 09 (document currently at 13)
Result Ready
Completed 2025-07-28
review-ietf-tls-8773bis-09-secdir-lc-weis-2025-07-28-00
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors. Document editors and WG chairs should treat these
comments just like any other last call comments.

The summary of the review is Ready.

This document documents a TLS 1.3 extension which augments the TLS key
schedule created from a (EC)DHE shared secret value with a pre-shared
key (PSK). It updates the method defined in RFC 8773, elevating the
status of that method to Standards Track, as well as adding additional
text due to changes in the more recent TLS 1.3 draft specification.
Other changes appear to be text added to better describe the motivation
for defining this method, e.g. updated  information regarding
Cryptographically Relevant Quantum Computer (CRQC) attacks. As there are
no substantive changes to the method, I believe it’s generally ready for
publication.

However, I do have a couple of suggestions.

1. As a first-time reader of the method I was very surprised that the
actual method of adding the External PSK was not revealed until the
Security Considerations section. I suspect this is due to the lengthy
rationale accompanying the specifics of how the PSK is added to
HKDF-Extract, but the method itself is relevant enough to be promoted to
its own section earlier in the document where it is more easily found
my implementors.

2. It’s not clear why the “should not” and many of the “must” statements
in Security Considerations are not capitalized, denoting them as
requirements per Section 2. Making them requirements (here or elsewhere
in the document) would improve the security of the document.

I also noticed two typos:

1. Page 11, middle: s/that one TLS 1.3 session/than one TLS 1.3 session/

2.The apostrophe character used in “Grover’s algorithm” does not seem to
be an ASCII character.