[TLS] Re: ML-DSA in TLS

[tirumal reddy <[e-mail]>]

On Fri, 15 Nov 2024 at 23:10, Andrey Jivsov <[e-mail]> 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?
>
The hybrid ML-DSA draft (see
https://datatracker.ietf.org/doc/draft-reddy-tls-composite-mldsa/) was
published before the standalone ML-DSA and we published a revised draft to
address the comments from the WG.

-Tiru


> On Fri, Nov 15, 2024 at 9:13 AM John Mattsson <john.mattsson=
> [e-mail]> 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 <[e-mail]>
>> *Date: *Friday, 15 November 2024 at 17:46
>> *To: *Bas Westerbaan <bas=[e-mail]>, [e-mail]
>> <[e-mail]>
>> *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.
>> _______________________________________________
>> TLS mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>