Hi Brian, Thank you for the review and suggestions. A few clarifications on point 1:
On 28.07.25 18:36, Brian Weis via Datatracker wrote:
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.
My reading is that Sections 4 and 5 are pointing to the change already, e.g., in Section 4:
> When the "tls_cert_with_extern_psk" extension is successfully negotiated, the TLS 1.3 key schedule processing includes both the selected external PSK and the (EC)DHE shared secret value.
and in Section 5.3:> Section 7.1 of [RFC8446] specifies the TLS 1.3 key schedule. The successful negotiation of the "tls_cert_with_extern_psk" extension requires the key schedule processing to include both the external PSK and the (EC)DHE shared secret value.
There is only one place in the TLS key schedule where external PSK can go, namely IKM input to the first HKDF-Extract. Hence, I believe it should be fine for the implementers.
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.
Writing it explicitly in the last paragraph of security considerations was part of informal justification that the formally proved guarantees of TLS 1.3 (in ProVerif) should continue to hold under traditional (non-PQ) adversary model.
Usama
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
