[TLS] Re: ML-DSA in TLS

[Deirdre Connolly <[e-mail]>]

The CNSA 2.0 FAQ states, "Do not use a hybrid or other non-standardized QR
solution on NSS mission systems except for those exceptions NSA
specifically recommends to meet standardization or  interoperability
requirements", and, "because NSA is confident that CNSA 2.0 algorithms will
sufficiently protect NSS, it does not require a  hybrid solution for
security purposes." They specifically cite IKEv2 as a hybrid exception.

https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF

On Mon, Nov 18, 2024, 8:37 PM Andrey Jivsov <[e-mail]> wrote:

> The reality is that we have very tight deadlines from CNSA2.0, with
>> customers actively asking for post-quantum support. For those for whom
>> those
>> requirements apply, use of ML-DSA is not only uncontroversial, but
>> mandatory.
>
>
> CNSA 2.0, as clarified in a recent FAQ, does not prohibit ML-DSA+ECC.
>
> On Mon, Nov 18, 2024 at 5:54 AM Alicja Kario <[e-mail]> wrote:
>
>> Answering to the broader thread: when I said "uncontroversial" I was
>> thinking
>> more about _how_ it should be done, not _if_ it should be used.
>>
>> Answer to email below follows.
>>
>> On Saturday, 16 November 2024 09:57:03 CET, D. J. Bernstein wrote:
>> > Watson Ladd writes:
>> >> Authentication is not like encryption.
>> >
>> > I presume that you're alluding to the following process: if the PQ
>> > signature system is broken, we revert to ECC signatures, and then the
>> > attacker doesn't benefit from forging the no-longer-accepted signatures
>> > (whereas we can't stop attackers from breaking previous ciphertexts).
>> >
>> > This process leaves computers completely exposed until they've reverted
>> > to ECC. Sure, some environments are fast to make changes, but some
>> > aren't. For comparison, using ECC+PQ in the first place avoids this
>> > security failure, and will make many people less hesitant to upgrade.
>> >
>> > The revert-in-case-of-disaster process also leaves computers completely
>> > exposed to PQ attacks that haven't come to the public's attention yet.
>> > Out of the 69 round-1 submissions to NIST, 33 have been publicly broken
>> > by now (see https://cr.yp.to/papers.html#pqsrc) with some of the
>> > attacks not published for years; is it so hard to imagine that
>> > large-scale attackers found some attacks before the public did?
>> >
>> > More broadly, conflating "no attacks have been published" with "no
>> > attacks are being carried out" is unjustified, an extreme form of
>> > availability bias. Occasionally there are leaks from attackers
>> > illustrating how much damage this mistake has done. Example:
>> >
>> >
>> >
>> https://www.washingtonpost.com/world/national-security/nsa-infiltrates-links-to-yahoo-google-data-centers-worldwide-snowden-documents-say/2013/10/30/e51d661e-4166-11e3-8b74-d89d714ca4dd_story.html
>>
>> All good points, ones I agree with, but I think those are arguments
>> against wide deployment of pure ML-DSA, not against describing how
>> the algorithms should be implemented on technical level.
>>
>> The reality is that we have very tight deadlines from CNSA2.0, with
>> customers
>> actively asking for post-quantum support. For those for whom those
>> requirements
>> apply, use of ML-DSA is not only uncontroversial, but mandatory.
>>
>> And personally, I'd prefer them using ML-DSA than LMS or XMSS...
>>
>> For the wider Internet, where we want fail-safe options, yes, hybrids are
>> probably better. Unfortunately, I don't think we have a rough consensus in
>> LAMPS on how hybrid signatures should be done just yet, and without that,
>> we can't standardise it for TLS.
>>
>> (that being said, I don't think ML-DSA will be completely broken
>> over-night,
>> I suspect it will be weakened over time, so migration off of it won't need
>> to happen with high agility... but only time will tell how it will play
>> out)
>> --
>> 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
>> <https://www.google.com/maps/search/Purky%C5%88ova+115,+612+00,+Brno,+Czech+Republic?entry=gmail&source=g>
>>
>> _______________________________________________
>> 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]
>