Hello all,
I object to the publication of this document, I think that would be a
bad idea.
First, this document lacks an important part of the motivation: what is
the reasoning for allowing a standalone (non-hybrid) ML-KEM?
Additionally, I would expect there to be "security considerations"
regarding this choice, as using non-hybrid PQ crypto is a bad idea [1].
The current "security considerations" section mentions that "hybrid key
establishment provides compositional security" (which is my point
exactly), but doesn't argue why disregarding that is appropriate.
Leaving that to the implementer ("security considerations" section, last
paragraph) is just asking for trouble.
Secondly, publishing as an RFC is an endorsement in practice, even if
we'd like to pretend otherwise. In my experience, the Informational
label means nothing (RFC 1591 anyone?), and the standard paragraph about
"not an Internet Standards Track specification" is ignored. Indeed,
anything published on ietf.org or rfc-editor.org gets regarded as
credible, seeing how many people took the IPv8 thing seriously.
Therefore, it would be irresponsible to publish this, especially so
without explicit mention of the potential issues.
[1] As many others have pointed out, using non-hybrid systems becomes
dangerous if the PQ component is broken with classical means (see SIKE).
--
Met vriendelijke groeten,
Wessel Jacobi
https://www.jacobi.pw
------------------------------
I prefer to use encrypted email. My public GPG key fingerprint is 6092
B1AB 7F60 AB78 000A 8331 FC3A A544 BE58 F812 and the key is available at
https://www.jacobi.pw/pgp.txt
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
