> I think this PR should mention risks introduced by hybrid solutions as well > – which (obviously) differ from those introduced by non-hybrid.
Mentioning them is certainly a good idea. Perhaps it makes sense to be specific as to what is compared: - I would consider hybrid methods beyond ietf-tls-ecdhe-mlkem (or whatever the WG decides is the best way to combine ML-KEM with a traditional KEX in the specific context of TLS) out of scope. - Potential drawbacks of ietf-tls-ecdhe-mlkem are best discussed within that document, as they represent securiy considerations for *any* potential implementers of that document. For instance, the fact that a memory safety issue in one KEX algorithm can affect the security of the entire program, whereas the effect of timing leakage is (should be?) limited to the specific KEX algorithm. - Insofar as we believe those reasons to be sufficient for switching to non-hybrids (at least in some contexts), draft-ietf-tls-mlkem should mention these contexts in the listing in the security considerations. Would this address your concerns adequately? -- TBB
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
