Q Misell <[email protected]> writes: > It is not our job in this case to judge if using pure ML-KEM or a > hybrid is a good idea or not, and the document explicitly states this, > by stating it is not an IETF recommended algorithm. Consequently, we > are not here to judge if the algorithm is a good idea, but merely if > standardisation is warranted to avoid implementation fragmentation. In > this case, it is almost trivial to conclude that it is worthwhile.
I don't think the above view is correct. If ten organization came up insisting to publish non-hybrid SIKE for TLS as an RFC (such as [1]), I would hope and expect the TLS WG to shoot it down because SIKE is insecure. So we ARE here to do more than only publish things. The TLS WG ought to take some responsibility for not publishing sub-optimal documents. When the decision what is optimal is difficult (as it seems here), there is the option to publish through the ISE track. Publishing TLS stuff on the Independent track has been done before for the Brainpool ECC curves and some Chinese SM ciphers. In THAT case the TLS WG do not get to judge anything. Then people who insists on an RFC get what they want. People who wants to get a code point for interop reasons sends an e-mail to IANA. /Simon [1] https://datatracker.ietf.org/doc/html/draft-campagna-tls-bike-sike-hybrid-07#name-requirements-language
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
