On Fri, Oct 10, 2025 at 3:48 AM D. J. Bernstein <[email protected]> wrote:
> Bas Westerbaan writes: > > Setting aside the question of use cases for a moment, let me note that no > > one even bothered to ask IANA to assign codepoints for any hybrid not > > already listed in this I-D. > > It seems that practically all of the real-world PQ usage in TLS is > specifically of the first option in the spec (X25519MLKEM768). See, > e.g., https://www.netmeister.org/blog/pqc-use-2025-03.html. > > Removing the other options (SecP256r1MLKEM768 and SecP384r1MLKEM1024) > from the spec would certainly resolve my concerns regarding the security > risks of including those options in the spec. > As has been noted a number of times, these code points are already registered with IANA, so I don't think removing them from this spec is particularly useful [0]. If there is WG consensus that we should be discouraging these options, we have other tools for doing that, namely marking them Recommended=N/D or even deprecating them. -Ekr [0] As I've noted before, it's not necessary to have an RFC to assign the code points, but given that the WG has spent the time to do so in this case, I don't think this constitutes an argument for removal.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
