On Friday, 25 October 2024 16:31:17 CEST, Eric Rescorla wrote:
On Thu, Oct 24, 2024 at 12:38 AM Bas Westerbaan <b...@cloudflare.com> 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
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
