On Friday, 15 November 2024 18:38:56 CET, Andrey Jivsov wrote:
I am curious why this draft exclusively proposes ML-DSA,
instead of adopting a composite signature approach as outlined
in draft-ounsworth-pq-composite-sigs, at least as an option. For
instance, id-MLDSA87-ECDSA-P384-SHA512 defined in the draft
aligns with CNSA 2.0.
Could supporters of the draft elaborate on the rationale to
favor or exclusively offer (?) a standalone ML-DSA? Or, will a
hybrid ML-DSA be in another draft?
We will definitely need a second draft with hybrid ML-DSA definitions.
The reason for pure ML-DSA is that for TLS use case, use of hybrids has
limited benefits. OTOH, we can be sure that for use cases like S/MIME
we will want clients that use hybrid algorithms, and we know that reusing
certificates for user authentication is quite common, so we will
need codepoints at the very least for clients. But then there's no point
in limiting it to clients only.
So, the reason for this draft focusing on ML-DSA only is simplicity:
How to use pure ML-DSA is uncotroversial, both in certs and in signatures,
so we can release this standard quickly.
On Fri, Nov 15, 2024 at 9:13 AM John Mattsson
<john.mattsson=40ericsson....@dmarc.ietf.org> wrote:
I'm unenthusiastic but don't strongly oppose adoption of this and
similar drafts, mostly because I think we should try get some WG
consensus on guidance for when these things may be needed (if ever)
and what the consequences might be should people deploy 'em in the
meantime. (By 'em I mean anything with any kind of PQ sig or non
hybrid PQ key exchange.) That guidance might or might not be in a
separate document, or be copied into each relevant one.
More discussion would certainly be welcome. IPSECME is
discussing what the right solution for hybrid PQC authentication
is. The two proposals are composite public keys and signatures
in a single certificate chain vs. two certificate chains. Both
approaches have benefits and disadvantages. TLS should have the
same discussion. Using two certificate chains is already
possible in TLS with Post-Handshake Certificate-Based Client
Authentication. Post-Handshake Certificate-Based Server
Authentication should be added anyway as it is needed for long
lasting TLS connections in infrastructure.
WebPKI might want to wait but the many infrastructure use cases
of TLS, DTLS, and QUIC need to migrate very soon. US government
new requirement is that pure RSASSA, ECDSA, and EdDSA are
forbidden from after 2035. European countries have similar
recommendations/requirements. Country to an earlier comment on
the list, industry does not like new shiny tools, to the
contrary, industry loves using existing stuff if possible.
https://csrc.nist.gov/pubs/ir/8547/ipd
https://cyber.gouv.fr/sites/default/files/2021/03/anssi-guide-mecanismes_crypto-2.04.pdf
but don't strongly oppose adoption
Please don’t. TLS is already seen as being behind LAMPS,
IPSECME, and JOSE. Any further delay would likely end up in a
lot of LSs from various infrastructure SDOs urging IETF to
specify quantum-resistant authentication in TLS ;)
Cheers,
John
From: Stephen Farrell <stephen.farr...@cs.tcd.ie>
Date: Friday, 15 November 2024 at 17:46
To: Bas Westerbaan <bas=40cloudflare....@dmarc.ietf.org>,
tls@ietf.org <tls@ietf.org>
Subject: [TLS] Re: ML-DSA in TLS
On 15/11/2024 10:51, Bas Westerbaan wrote:
We have posted a -00.
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tls-westerbaan-mldsa-00&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb8e9b9505c8a47465c1308dd0594fae8%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638672859618372708%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=CHrEsED8VIB%2FotGnx3i8Es%2BHyquLY6NZAxAaTz8ANnM%3D&reserved=0
I'm unenthusiastic but don't strongly oppose adoption of this and
similar drafts, mostly because I think we should try get some WG
consensus on guidance for when these things may be needed (if ever)
and what the consequences might be should people deploy 'em in the
meantime. (By 'em I mean anything with any kind of PQ sig or non
hybrid PQ key exchange.) That guidance might or might not be in a
separate document, or be copied into each relevant one.
Cheers,
S.
--
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
