TLS 1.3 Extension for Using Certificates with an External Pre-Shared Key
draft-ietf-tls-8773bis-13

Yes

Deb Cooley
Erik Kline
Mike Bishop
Paul Wouters

No Objection

Andy Newton
Gorry Fairhurst
Gunter Van de Velde
Jim Guichard
Ketan Talaulikar
Mohamed Boucadair
Roman Danyliw
Éric Vyncke

Note: This ballot was opened for revision 10 and is now closed.

Deb Cooley
Yes
Comment (2025-09-02 for -10) Sent 
Thanks to Brien Weis for their secdir review. 

Security Considerations, para 4:  This is a key consideration, thank you for adding it. 

Normative References:  I don't see that the mention in the Intro makes draft-ietf-emu-bootstrapped-tls normative, but it certainly isn't an issue.

Informative References:  I do think that draft-ietf-tls-rfc8446bis is normative.  Possibly this has confused various reviewers?
Erik Kline
Yes
Mike Bishop
Yes
Comment (2025-09-02 for -10) Sent 
Section 4: "MAY also find it useful" means that the client is permitted, but not required, to find the extension useful. Is that the intended sense? I'd suggest that this is a lowercase "may" or better yet "might".
Paul Wouters
Yes
Andy Newton
No Objection
Gorry Fairhurst
No Objection
Comment (2025-08-28 for -10) Sent 
Thank you for preparing this well-written document. This seems like 
it is could be an important document for future designs.

I would have appreciated a little more introductory text to introduce an
External PSK in section 1. The basis of such short text could already exist
in the security considerations, as per comment 1 of the security area review:
https://datatracker.ietf.org/doc/review-ietf-tls-8773bis-09-secdir-lc-weis-2025-07-28/

If I understand, I think it could be helpful (you will know) to note that 
the discussion in the Security Considerations describes requirements in
the main body and does not provide additional security-specific requirements.

NiT
===
/In particular, The/In particular, the/
Gunter Van de Velde
No Objection
Jim Guichard
No Objection
Ketan Talaulikar
No Objection
Mohamed Boucadair
No Objection
Comment (2025-09-03 for -10) Sent 
Hi Russ, 

Thanks for the effort put into this specification. 

I only reviewed the diff vs RFC8773.  

# I-D.ietf-tls-rfc8446bis should be listed as normative.

# I-D.ietf-emu-bootstrapped-tls should be cited as informational given that the only citation is:

CURRENT:
   Another motivation is the use of a public key with a factory-
   provisioned secret value for the initial enrollment of a device in an
   enterprise network [I-D.ietf-emu-bootstrapped-tls].

# Nit: for readers convenience, please point to the exact section where this is defined 

OLD:
   The Extension structure is defined in [I-D.ietf-tls-rfc8446bis]; it
   is repeated here for convenience.

NEW:
   The Extension structure is defined in Section 4.2 of [I-D.ietf-tls-rfc8446bis]; it
   is repeated here for convenience.

Cheers,
Med
Roman Danyliw
No Objection
Comment (2025-09-02 for -10) Not sent 
Thank you to Christer Holmberg for the GENART review.
Éric Vyncke
No Objection
Comment (2025-08-28 for -10) Sent 
Thanks for the work done in this document.

The reader would probably welcome explanations about why a PSK may be used with certification authentication (last paragraph of section 5.2); if a PSK is set between a TLS client and a TLS server, then I really wonder what is the added value of certs based authentication on the top (just to show that I do not know TLS 1.3 inside-out).