[TLS] Re: ML-DSA in TLS

[Alicja Kario <[e-mail]>]

On Friday, 25 October 2024 16:31:17 CEST, Eric Rescorla wrote:
>
>
> 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.
>

disabling things is frequently available through user config, we went
through that recently with DSA, enabling things requires support in code
for those new features, that's much more involved

-- 
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