>Compare the migration away from MD4, MD5, DSA, DES, RC4. MD2, MD4, MD5, and RC4 were all horribly broken. DSA and DES were standardized by NIST and have not been broken. The lesson from these examples is: use standardized cryptography, don’t use non-standardized cryptography.
Cheers, John On 2025-10-20, 17:11, "Simon Josefsson" <[email protected]> wrote: Eric Rescorla <[email protected] <mailto:[email protected]>> writes: >> *EKR wrote:*>It's purely about whether we think it's reasonable to >> implement. >> >> This is the current meaning. RFC8447bis will change the meaning to: >> >> “This only means that the associated mechanism is fit for the >> purpose for which it was defined.” > > Right. Is it not the opinion of the TLS WG that P256/P-384 + MLKEM are fit > for that purpose? RFC8447bis requires IETF-consensus. I don't think that question has been asked IETF-wide at all so far, has it? Has there been any consensus call in the TLS WG on that question even? So we don't really know. > If not, on what basis, given that we require you to implement P-256 alone? I don't think this comparison with historic MTI of P-256 alone is relevant for deciding about P256+MLDSA today. It is reasonable that we required you to implement something a couple of years ago that we wouldn't require you to implement today, but we haven't gotten around to publishing an updated document. Compare the migration away from MD4, MD5, DSA, DES, RC4. The tendency to move beyond those algorithms happened long time before we got around to drop them from recommended/MTI status. By that line of reasoning, it would make sense to standardize and make MTI the brainpoolP256 curve too. I don't think that is reasonable today, so I think the analogy is invalid as an argument. /Simon
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
