Hi,Speaking as member of ITU-T (in SG17; not the one initiating this LS), I want to thank John for initiating a draft response, which I believe is right on spot. Our chair, Arnaud, has kindly offered to do a review but I am aware that he has quite some meetings and travel in the next 2 weeks. So I am giving some quick feedback in the mean time. While I don't find anything "inflammatory" in it (as someone has suggested), it's fine to make a few editorial changes but make sure the core message is not lost in these changes. Please remove RFC8773 and use only RFC8773bis. The reason is that proposal [0] in RFC8773 is *fully inconsistent* with the key schedule of TLS 1.3, since the very first key (Early Secret) is derived in a wrong way and thus all subsequent secrets are wrong too. Technical reasoning is in [1].
Speaking as member of TLS WG:I disagree with Ekr. I believe TLS WG is the right place for this LS and TLS WG has the right expertise as RFC8773bis is indeed a WG item of this WG.
I disagree with Viktor with his mention of KEMs for RFC8446. That's not correct. RFC8446 explicitly mentions (EC)DHE and never mentions KEMs.
I completely agree with Stephen to not say anything about pure ML-KEM to avoid that controversy here. Let's have a peaceful weekend without pure ML-KEM thingy. 🙂
Sincerely, -Usama [0] https://www.rfc-editor.org/rfc/rfc8773.html#section-7-14 [1] https://mailarchive.ietf.org/arch/msg/tls/6Wk82oBGd61rTK23DgfYb7BmRKM/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
