Yes, the thread on this draft got hijacked by a completely off-topic discussion about composite and hybrid.
To be clear, the draft says absolutely nothing about either of those two topics, and to be even more clear, does not at all imply in any way that pure ML-DSA is superior or is the only option. It just says that if you need ML-DSA for TLS, here’s how you do it. People who want to discuss composite / hybrid, which by the way I personally am also in favor of and actually prefer for many use cases, should move those discussions to threads about the appropriate drafts. ML-DSA support for TLS is obvious and straightforward. We should explain and standardize the right way to do it, to prevent people from inventing a plethora of slightly different, non-standard implementations out of necessity because IETF failed to publish a straightforward draft in a timely manner. Let’s get back on topic and get this done. -Tim From: Scott Fluhrer (sfluhrer) <sfluhrer=40cisco....@dmarc.ietf.org> Sent: Thursday, November 21, 2024 8:55 AM To: Andrey Jivsov <cry...@brainhub.org>; Eric Rescorla <e...@rtfm.com> Cc: tls@ietf.org Subject: [TLS] Re: ML-DSA in TLS Might I ask what are we arguing about? Does the TLS working group feel the need to prohibit pure ML-DSA as authentication? Even though, after Q-day happens (whenever that will be), that might be what people want? If you go through the TLS ML-DSA draft, all they do is define three code points (for the three ML-DSA parameter sets), that’s it. That sounds like a reasonable addition, even if it were to turn out to be useful only in a few networks with private CAs. From: Andrey Jivsov <cry...@brainhub.org <mailto:cry...@brainhub.org> > Sent: Wednesday, November 20, 2024 3:36 PM To: Eric Rescorla <e...@rtfm.com <mailto:e...@rtfm.com> > Cc: tls@ietf.org <mailto: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 <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>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
