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
