[TLS] Re: ML-DSA in TLS

[Bas Westerbaan <[e-mail]>]

>
> I'm not sure I agree that there is no value. In general, we try to roll
> out new mechanisms slowly so that we get some experience with how they
> perform in the wild. Given the experience with PQ key establishment, we
> should probably have some concern that ML-DSA won't just work in all cases,
> and we'd like to find that out now, which requires some level of deployment.
>

I am well aware, and we will, as we have before.

But I think we've strayed from the original question you asked:

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.


I think we should at least standardize pure ML-DSA. That does not prevent
us from standardising a hybrid as well. These are independent matters.

Best,

 Bas


PS. Majority of testing can be done without hybrids. Don't run it on
production traffic. Or pad a P-256 key to the length of ML-DSA. If it's
compute we want to test, run a dummy ML-DSA verify. If we do want the full
thing with a hybrid, we can use an ad hoc hybrid (as CECPQ2 was ad hoc too.)




>
>
>> The proposal you sketch also requires an update at the time CRQCs are
>> near to disable the non-PQ certificates.
>>
>
> Absolutely. We're just in an asymmetrical position in that we're already
> exposed to the risk of non-PQ but not to the risk of PQ.
>
> -Ekr
>
>
>> If you have a system that cannot have an update, then you indeed need a
>> hybrid.
>>
>>
>>> 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]
>>>>>>
>>>>>