[TLS] Re: ML-DSA in TLS

[Eric Rescorla <[e-mail]>]

On Thu, Oct 24, 2024 at 12:38 AM Bas Westerbaan <[e-mail]> wrote:

> Today for the WebPKI there is no security benefit to enabling post-quantum
> certificates (in stark contrast with post-quantum key agreement.) On the
> other hand, there is a big cost with extra bytes on the wire. As it stands,
> we do not intend to enable post-quantum certificates by default before the
> CRQC is near. At that point, there is little value in hybrid certificates.
> There is value in having post-quantum certificates ready-to-go now (without
> flipping the switch.) And for that pure ML-DSA makes more sense.
>

Hi Bas,

I'm not sure I agree with this analysis, but perhaps it depends on
what you mean by "ready-to-go".

I would think that the natural thing to do here is to get fairly
widespread deployment of support for PQ certificates but then prefer
non-PQ certificates. I.e.,

1. Clients would support both PQ and non-PQ certificates.
2. Servers would have both PQ and non-PQ certificates, but would
   provide the non-PQ certificate if the client supported it.

This would enable clients to decide that the risk from non-PQ was high
(as you say "the CRQC is near") and disable non-PQ.  Note that it
doesn't matter whether the server supports non-PQ as well, as the
security benefit comes from the client refusing it [0]. Do we agree so
far?

In general, the client is exposed to the union of the risks of
compromise of the signature algorithms it supports. Thus, in a world
where the client supports: [ECDSA, ML-DSA], then compromise of either
algorithm is an issue. By contrast, if the client supports [ECDSA,
EC-DSA+ML-DSA], then compromise of ML-DSA alone is insufficient to
result in an attack. This is of course the same logic that leads
to hybrids for key establishment.

An obvious response here is "if something goes wrong with ML-DSA,
we'll just turn it off quickly". This is certainly true for browsers,
but I'm less sure it's true for other systems. If you think that
it takes a long time to disable algorithms, then it seems like
that's an argument that hybrid signatures are safer.

-Ekr


[0] There is benefit in the servers supporting PQ ahead of time
because the client will have to make a cost/benefit decision in
terms of breakage, and the more servers support PQ, the easier
this decision is.













>
> It's uncomfortable though if the first blessed SignatureScheme would be a
> non-hybrid. (Also regulators don't make the distinction between
> authentication and encryption, but at least most of them insist on hybrids
> for both though.)
>
> So I agree it makes sense to set recommended=N for now.
>
> Best,
>
>  Bas
>
>
>
> On Thu, Oct 24, 2024 at 4:47 AM Eric Rescorla <[e-mail]> wrote:
>
>> I think an adoption call is a bit premature here. We've got some time,
>> especially in the WebPKI setting.
>>
>> In particular, we should have a discussion of whether we want to
>> standardize pure ML-DSA or hybrid ML-DSA/EC algorithms; I currently lean
>> towards the latter, but I, at least, would like to hear arguments to the
>> contrary.
>>
>> -Ekr
>>
>>
>> On Wed, Oct 23, 2024 at 11:02 AM John Mattsson <john.mattsson=
>> [e-mail]> wrote:
>>
>>> Let’s have an adoption call asap.
>>>
>>>
>>>
>>> I made some minor suggestions
>>> https://github.com/bwesterb/tls-mldsa/pull/3
>>>
>>>
>>>
>>> John
>>>
>>>
>>>
>>> *From: *Alicja Kario <[e-mail]>
>>> *Date: *Wednesday, 23 October 2024 at 19:59
>>> *To: *Bas Westerbaan <bas=[e-mail]>
>>> *Cc: *<[e-mail]>
>>> *Subject: *[TLS] Re: ML-DSA in TLS
>>>
>>> Hi,
>>>
>>> Thanks for the draft, will definitely be helpful.
>>>
>>> Few issues:
>>>  * The range 0x0900-0x0903 is reserved for backwards compatibility
>>>    I think it will be better to continue the numbering in the 0x08..
>>> space
>>>  * the must in "must use id_ML-DSA(...)" probably should be capitalised,
>>> as
>>>    if it doesn't match, the connection needs to be aborted
>>>
>>> open question is if we should document error handling explicitly:
>>>  - illegal_parameter alert if the peer used algorithm not advertised, or
>>>    signature algorithm does not match the certificate
>>>  - decrypt_error when verification of the signature failed
>>>
>>> On Wednesday, 23 October 2024 19:29:06 CEST, Bas Westerbaan wrote:
>>> > Hi all,
>>> >
>>> > Unless I overlooked something, we don't have a draft out to
>>> > assign a SignatureAlgorithm to ML-DSA for use in TLS.
>>> >
>>> > It's two days past the I-D submission deadline, but I wanted to
>>> > point you to a short draft we put together to fill this gap.
>>> >
>>> >
>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbwesterb.github.io%2Ftls-mldsa%2Fdraft-tls-westerbaan-mldsa.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C8fef63d5eddc4cb44fee08dcf38c63f4%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638653031501883034%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=1oIREiL3cz5iRqrSRQ2PKnw5%2BdAkv89rBl9AnUJwAgs%3D&reserved=0
>>> <https://bwesterb.github.io/tls-mldsa/draft-tls-westerbaan-mldsa.html>
>>> >
>>> > So far, I see only one open question: whether to set a non-zero
>>> > context string.
>>> >
>>> > Best,
>>> >
>>> >  Bas
>>> >
>>> >
>>> >
>>>
>>> --
>>> Regards,
>>> Alicja (nee Hubert) Kario
>>> Principal Quality Engineer, RHEL Crypto team
>>> Web:
>>> https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cz.redhat.com%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C8fef63d5eddc4cb44fee08dcf38c63f4%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638653031501906645%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=OEPmJIyNseoOyEubpjkOsGFhcqmd2HRTqwKcj4Xwkqk%3D&reserved=0
>>> <http://www.cz.redhat.com/>
>>> Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
>>>
>>> _______________________________________________
>>> 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]
>>>
>>