> I believe that adopting the draft will allow those who > wish to use pure PQC (for whatever reasons they may > have) to do so while at the same time not in any way > impacting anybody else who doesn't want to do that.
Those who wish to use pure PQC do not need permission. This is about IETF _endorsement_. Endorsement is based on many factors. ..." by googling "deploy ML-KEM now" and being recommended this rather than a safer hybrid[1]. I am not convinced that such a person, if given more knowledge, "doesn't want to do that". This assumes that “more knowledge” must lead to “don’t do ‘pure’”. Which is “purely” wrong – there are several aspects of a solution that contribute to or detract from “safety”, and the theoretical truism of “combination of different (independent) algorithms is generally stronger” is merely one – not even the biggest – part of it. Deirdde> As a coauthor on hybrid publications and I-Ds, I do not agree that hybrids are categorically safer. The -tls-hybrid-design for hybrids is pretty great... if you use secure component algorithms. Deirdre is absolutely correct. And even when the components are strong now – remember that the key (no pun intended) point of this exercise is to deal with CRQC, which will make all of the Classic components immediately useless.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
