Yep I mistakenly forgot to change the category to "info" instead of "std". It will be fixed in a future update.
Alie ________________________________ From: Andrey Jivsov <cry...@brainhub.org> Sent: Wednesday, November 20, 2024 2:35 PM To: Eric Rescorla <e...@rtfm.com> Cc: tls@ietf.org <tls@ietf.org> Subject: [TLS] Re: ML-DSA in TLS Given that the series of Suite B RFCs were Informational, it stands to reason that a document of the type that e.g. prohibits hybrids because of internal policies of any organization, a viewpoint which is not strongly shared by IETF, should not be a standards-track document. For what I see, no-hybrids policy increases complexity in real-world systems that need to expose a hybrid and its components as a separate option, and this is especially difficult for systems that must have a single option acceptable to everyone. TLS https://datatracker.ietf.org/doc/html/rfc5430 IPSec https://datatracker.ietf.org/doc/html/rfc6380 SMIME https://datatracker.ietf.org/doc/html/rfc6318 OpenPGP: there was pushback on Standards-track, and it only could get standards track after we made sure that Brinpool curves are supported https://www.rfc-editor.org/rfc/rfc6637.html (The difference in practice may not be significant, but I still think that Informational is correct) On Wed, Nov 20, 2024 at 9:22 AM Eric Rescorla <e...@rtfm.com<mailto:e...@rtfm.com>> wrote: On Wed, Nov 20, 2024 at 6:06 AM D. J. Bernstein <d...@cr.yp.to<mailto:d...@cr.yp.to>> wrote: https://web.archive.org/web/20240925031754/https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF includes the following note: "Even though hybrid solutions may be allowed or required due to protocol standards, product availability, or interoperability requirements, CNSA 2.0 algorithms will become mandatory to select at the given date, and selecting CNSA 1.0 algorithms alone will no longer be approved." This looks 100% compatible with a TLS WG decision saying "PQ in TLS has to be hybrid". Without addressing the question of what CNSA 2.0 requires, I don't think the TLS WG making that decision is really on the table here. As a reminder, the relevant TLS registry (https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8) operates under an "Expert Review" policy with the standard being quite low. Note: The role of the designated expert is described in RFC 8447<https://www.rfc-editor.org/rfc/rfc8447>. The designated expert [RFC8126<https://www.rfc-editor.org/rfc/rfc8126>] ensures that the specification is publicly available. It is sufficient to have an Internet-Draft (that is posted and never published as an RFC) or a document from another standards body, industry consortium, university site, etc. The expert may provide more in-depth reviews, but their approval should not be taken as an endorsement of the supported group. So, the question isn't so much whether a given algorithm can be used with TLS but rather (1) whether the WG adopts it (2) whether it's standards track, (3) whether we mark it Recommended and (4) whether it's mandatory to implement. We certainly could mark ML-KEM Recommended=N (or even D), but the policy isn't to forbid code point registration just because we don't have confidence in the algorithm; I don't think we should change that in this case. -Ekr _______________________________________________ TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org> To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org>
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
