Ryan Hurst
On Mon, May 27, 2024 at 2:31 AM Dennis Jackson
<ietf=40dennis-jackson...@dmarc.ietf.org> wrote:
One of the key use cases proposed for Trust Expressions is
enabling a speedy deployment of PQC Certificates. I agree
this is an important use case to address, but I think a
closer inspection of the existing deployment options shows
that Trust Expressions does not provide any improvement or
new functionality over existing, already widely deployed
solutions.
In particular, having each CA cross-sign their new PQC root
with their existing classical root. This does not require any
new functionalities or code changes in TLS clients or
servers, does not require coordination between CAs / Root
Programs / Clients and does not impose any performance impact
on the connection (perhaps surprisingly).
The rest of this message details the Trust Expressions
proposal for a PQC transition and compares the security and
performance to existing solutions.
*The Trust Expressions Proposal for the PQC Transition
*When we come to transition to PQC Certificates, the various
Root Programs will include various PQC Roots and start
distributing them to their clients. They will also configure
their clients to start advertising the relevant PQC / hybrid
signature algorithms in their signature_algorithms_cert TLS
Extensions. TLS Servers will decide whether to send their
classical chain or their PQC chain according to this extension.
The Trust Expressions authors plus quite a few folks on the
list have stated that this approach will require us to wait
for all major root programs to accept a given PQC Root and
then for that PQC root to be ubiquitously supported by all
clients which also advertise PQC Signature Support.
Otherwise, we might send our new PQ Chain to a client who
only has an older set of PQ Roots, which would cause a
connection failure. This wait could take a long time, even a
year or more.
Trust Expressions proposes that by having clients indicate
their trust store label and version, we can mostly skip
waiting for ubiquity. Through the Trust Expression's
negotiation, we can be sure that we only send the PQC Root
Certificate Chain to clients that have already updated to
trust it. Meanwhile, clients that don't have PQC Signature
support or do support the signatures but don't have the new
PQC root will continue to receive the old classical chain and
not enjoy any PQ Authentication.
*The Existing Alternative
*I believe this argument for the use of Trust Expressions
overlooks existing widely available deployment options for
PQC Certificates, which mean that we do not need to wait for
multiple root stores to include new PQC certs or for them to
become ubiquitous in clients. We will see how we can achieve
the exact same properties as Trust Expressions (no waiting
for ubiquity, no connection failures and PQ-Auth for all
clients with the PQ Root) without the need for any new
designs or deployments.
When CAs create roots with new signature algorithms (e.g.
ECDSA Roots), it is common practice to cross-sign the new
root with the existing root (e.g. an RSA Root). This is the
approach taken by Let's Encrypt today, who have an older RSA
Root (ISRG X1) and a newer ECDSA Root (ISRG X2). X2 is cross
signed by X1, and each of the new ECDSA Intermediates are
also cross-signed by X1 [1]. In the context of RSA vs ECDSA,
this isn't especially interesting because there's a purely a
tradeoff between a smaller chain (ECDSA/X2) vs a more
ubiquity (RSA/X1). However, we'll see this approach has much
more substantial benefits with PQC Signatures.
When the time comes to ship a PQC Root (which we'll call X3
for convenience), we'll make some PQC Intermediates (F1, F2,
F3). We will also cross sign these intermediates with our X2
(ECDSA) Root which we'll call H1, H2, H3. So both F1 and H1
are certificates on the same intermediate PQC Public Key,
with F1 having a PQC signature and H1 a ECDSA signature from
their respective roots.
When we provision servers with their certificate chains,
we'll provision the PQC Chain as their leaf (PQC Public Key +
PQC Signature), plus both F1 and H1. Clients that don't
indicate support PQC Signatures in their
signature_algorithms_cert extension will receive the usual
classical chain. Clients that support PQC and have the new
root will verify the leaf + F1 and so enjoy PQ-Auth. Clients
that support PQC and don't have the new root will verify the
leaf and H1 and not receive PQ-Auth.
This achieves identical properties to Trust Expressions in
terms of client security and doesn't involve any waiting for
PQC Root Ubiquity or Root Store Approval. The only impact is
the extra certificate in the chain. Happily, we can cut the
overhead of H1 to be a mere 32 bytes with existing TLS
Certificate Compression Algorithms like zlib / zstd / brotli
(since H1 and F1 encode the same PQC Public Key). This is
tiny compared to the necessary PQC Public Key and Signature
already in the chain. With new schemes like Abridged Certs,
we can go even further and replace all but the leaf
certificate with two-byte identifiers.
There are several alternatives available as well depending on
the exact use case. For example, we could send only F1 (PQC
Intermediate chaining to X3) and an X3 Root signed by X2 -
ensuring there's only a single chain and no path building
support required. Clients with the X3 PQC Root will not need
to check the final ECDSA signatures, others will. With
existing TLS Certificate Compression algorithms, this
compresses slightly worse than the dual-intermediates chain,
but Abridged Certs works just as effectively. AIA Chasing is
also deployed in Chrome and could be used to fetch this final
cross-sign certificate if desired, although I think stateless
mechanisms like Certificate Compression with zlib are preferable.
In the event we'd like to make a second future transition,
e.g. from a hybrid PQC signature scheme to a solely PQC
scheme, or between PQC schemes, the same approach as above
works just as well. I would fully expect by time we'd be
considering a second transition, we'd either have mature
deployment of solutions like intermediate suppression or
abridged certs, or we'd be considering a move away from X.509
entirely to a newer, slimmer, PKI system.
Overall, I hope this is convincing that the Trust Expressions
design does not achieve any improvements over existing
technology for transitioning to PQC Certs and so I think we
can set this proposed use case aside from the wider discussion.
*Wider Thoughts on the PQC Transition
*
In isolation, drafts like Abridged Certs and Trust
Expressions can each deliver roughly the same size PQC
Certificate Chains, able to compress down everything but the
leaf certificate to just a couple of bytes. Depending on
whether you expect PQC Signatures for SCTs, this gives an
overall size of either ~4 KB - similar to RSA Chains today -
or a rather unpalatable ~9 KB.
Although recent work on improved CT log implementations like
Sunlight is vital for the ecosystem and fantastic to see, I'm
still quite concerned about the long term story for a Post
Quantum PKI with strong transparency guarantees. There are
existing proposals like Merkle Tree Certificates which look
to eliminate X.509 entirely and replace signatures with
proofs of inclusions. I think these ideas are pretty exciting
and with refinement could be a promising way forwards, but do
have a few open problems that we still need to solve
(especially on the transparency and availability aspects).
However, we do not need Trust Expressions to do Merkle Tree
Certs or any alternative design, these features would
necessarily need their own negotiation mechanism and so we
should not confuse the two proposals.
Best,
Dennis
[1] https://letsencrypt.org/certificates/ *
*
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
