Hello together, I have just opened a pull request related to the hybrid vs. non-hybrid discussion, to highlight a possible compromise. For those who prefer mail, I have included the PR description below.
Best, -- TBB ----- BEGIN PR ----- This PR is an attempt to strike a balance between - those who would like to deploy ML-KEM as a non-hybrid, and - those who believe that a non-hybrid is not the best choice for the average user. In essence, it leaves the code point registrations (for interop), but clarifies that the choice to deploy a non-hybrid should only be taken in acknowledgement of the possible risks involved. This is done first and foremost by setting the recommended column in the IANA registration to Discouraged. According to draft-ietf-tls-rfc8447bis: > D:Indicates that the item is discouraged. This marking could be > used to identify mechanisms that might result in problems if they > are used, such as a weak cryptographic algorithm or a mechanism > that might cause interoperability problems in deployment. When > marking a registry entry as “D”, either the References or the > Comments Column MUST include sufficient information to determine > why the marking has been applied. Implementers and users SHOULD > consult the linked references associated with the item to > determine the conditions under which the item SHOULD NOT or MUST > NOT be used. Perhaps taking could a bit too seriously for the original intent, the last sentence is exactly the mechanism this PR wishes to leverage. The security considerations have been extended by (the beginnings of; Please extend this!) a section about non-hybrids, and this section is intended to highlight and explain the use cases in which a non-hybrid might be a good fit. I have also made some changes to the motivation, to explain the D column early in the document. Goes without saying, but everything here is up for discussion :) ----- END PR -----
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
