On Thursday, 21 November 2024 19:23:12 CET, Tim Hollebeek wrote:
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.
Precisely my point.
I don't want a repeat of the mess that RFC 8734 created.
So, even if I don't think the algorithm is the best choice around,
having the specification go through WG means that it receives more
and better feedback.
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>
Sent: Wednesday, November 20, 2024 3:36 PM
To: Eric Rescorla <e...@rtfm.com>
Cc: 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> 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.
The designated expert [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
--
Regards,
Alicja (nee Hubert) Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
