On Friday, 15 November 2024 18:12:28 CET, John Mattsson 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.
No. Please, no.
Hybrids should be part of certificates.
Once we figure out how to do hybrid in X.509, the TLS use case follows.
I'm of the opinion that IPsec is the same. We don't need anything similar
to the hybrid "anything goes" construction that's in IPsec for
the key exchange.
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<https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-mldsa-00>
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
