Hi Brian,
Thank you for the review and suggestions. A few clarifications on
point 1:
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
<<attachment: smime.p7s>>
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
