Answers inline. I will only bother to answer questions others might have as
well, and ignore the rather laughable legal speculation.
> "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.
>
>
And you would have a point if this was a decision between a known broken
scheme and a known to be secure construction.
As it stands, ML-KEM is a secure cryptographic scheme, certainly secure
enough that a sophisticated user might want to choose it over 0x11ec.
With the United States government, there is at least one such, fairly large
user who would like to make that decision, and while you can say many
things about the NSA, lack of cryptographic expertise is not one of them.
By recommending 0x11ec, the average user will be guided to make the
slightly more conservative choice, but I do not feel like it would be a
dereliction of my duty as a cryptographer to merely allow the use of pure
ML-KEM, a statement I would not make about RC4.
* 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.
>
No rubberstamping is taking place. If we were rubberstamping things, we
wouldn't be having this discussion. This is also far from the first time
this topic has come up, and least from what I did see, the draft has been
discussed on its merits thoroughly, both on list and in meetups, and has
prevailed.
--
Sophie Schmieg | Information Security Engineer | ISE Crypto |
sschm...@google.com
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
