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> wrote: > > > On Wed, Nov 20, 2024 at 6:06 AM D. J. Bernstein <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 > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
