Sophie Schmieg writes:
> I do not see a security concern with having the option for pure ML-KEM in
> TLS. TLS has ways of negotiating algorithms, if one side believes ML-KEM to
> be insufficiently secure, they can negotiate 0x11EC (which equally should
> be adopted).
"I do not see a security concern with having the option for RC4 in TLS.
TLS has ways of negotiating algorithms. If one side believes RC4 to be
insufficiently secure, they can negotiate CBC."
Here are three basic problems with the generic argument that IETF should
delegate security decisions to users:
* Security is not easy to evaluate. Asking random users to make
security decisions is a recipe for disaster. Blaming users for the
resulting failures simply perpetuates the problem.
* BCP 188 says that "The IETF Will Work to Mitigate Pervasive
Monitoring". This implies an obligation to proactively address
security risks. Rubber-stamping specs, rather than evaluating
security, is contrary to that; even worse, it's inviting attackers
to once again manipulate the standardization process.
* IETF standards are subject to a legal obligation to follow
"objective criteria for selecting the technology to be included in
the standard". By itself, this doesn't contradict a "standardize
everything and let the users decide" approach; but IETF certainly
doesn't endorse _all_ proposed technology specs, so it needs to be
able to point to the criteria that it uses to select _some_ specs.
---D. J. Bernstein
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
