Starting a new thread to keep it off the adoption call thread.
I'm still forming my opinion on this topic. To that end, perhaps it's
most useful to focus in on the post-quantum case, as I think that's
the one that the WG finds most compelling. This message tries to work
through that case and the impact of TAI.
I apologize in advance for the length of this message, but I wanted
show my thinking, as well as make it easier to pinpoint where I may
have gone wrong if people disagree with this analysis.
CURRENT SETUP
Here's what I take as the setting now:
1. We have a set of existing CAs, numbered, 1, 2, 3...
2. CA_i has a trust anchor TA_i which is embedded in clients and then
used to sign an intermediate certificate I_i.
3. Servers have end-entity certificates signed by intermediates,
so we can denote server s's certificate signed by CAI i as
EE_s_i. The chain for this certificate is (proceeding from the
root): T_i -> I_i -> EE_s_i
These all use traditional algorithms (assume there's just one
traditional algorithm for simplicity).
ADDING PQ
When the CA wants to roll out PQ certificates, the following happens.
1. It generates a new separate PQ trust hierarchy, that looks like:
Tp_i -> Ip_i -> EEp_s_i.
2. It cross-signs its own PQ trust anchor with its traditional trust
anchor.
So abusing notation a bit, a server would have two certificate chains:
- Traditional: T_i -> I_i -> EE_s_i
- PQ: T_i -> Tp_i -> Ip_i -> EEp_s_i
Note that I'm assuming that there's just one CA, but of course
there could be two CAs, in which case the chains will be entirely
distinct:
- Traditional: T_i -> I_i -> EE_s_i
- PQ: T_j -> Tp_j -> Kp_j -> EEp_s_j
This actually doesn't matter (I think) for the purposes of this
analysis because the server can only send one EE cert.
CERTIFICATE CHAIN NEGOTIATION
When the client connects, it signals which algorithms it supports in
signature_algorithms. The server then selects either the traditional
chain or the PQ chain and sends it to the client depending on the
algorithm. This is how we've done previous transitions so there
shouldn't be anything new here.
The entire logic above is rooted in trusting whatever traditional
algorithm is in T_i. But the reason we want to deploy PQ certificates
is not for efficiency (as with EC) but because we want to stop
trusting the traditional algorithms. We do that by a two-step process
of:
1. Clients embed Tp_i in their trust list.
2. At some point in the (probably distant) future, they just deprecate
support for existing traditional trust anchors.
This means that there (again simplifying) there are at least four kinds of
clients.
1. Trust T_i. No PQ support.
2. Trust T_i. Traditional and PQ support.
3. Trust T_i and Tp_i. Traditional and PQ support.
4. Trust Tp_i. No traditional support.
However, the server only gets the "signature_algorithms" extension,
which looks like so:
Client Status signature_algorithms
Algorithms Trust Anchors
-------------------------------------- --------------------
1. Traditional T_i traditional
2. Traditional + PQ T_i traditional + pq
3. Traditional + PQ T_i + Tp_i traditional + pq
4. PQ Tp_i pq
Cases (1) and (4) are straightforward, because the server only has one
option. However, the server can't distinguish (2) and (3). There are
two possibilities here:
* The server wants to use a traditional certificate chain (e.g.,
for performance reasons). In this case, there isn't an issue
wants to use a traditional certificate because it can just send
traditional chain.
* The server wants to use a PQ chain. In this case, because it
can't distingish (2) and (3) it has to send the cross-signed Tp_i,
even though the client may already have it.
On the more global scale, the server has no way of measuring how many
clients trust Tp_i, and so isn't able to determine when it's largely
safe to unilaterally elide T_i when using the PQ chain. Note that the
server *can* determine when it's safe to stop presenting a traditional
EE cert at all by measuring the rate at which clients offer PQ
algorithms in signature_algorithms, because those clients are either
type (2) or type (3) and will in any case accept the longer chain.
As far as I can tell, none of this is relevant to the question of
security against quantum computers, because what provides that
property is that clients refuse to accept traditional algorithms at
all (type (4)), which is easily determined from signature_algorithms.
TRUST ANCHOR IDENTIFIERS
As far as I can tell, TAI changes the situation in two main ways:
1. It allows servers to distinguish clients type (2) and (3), so that
they can elide the extra certificate for type (3). This is
effectively an alternative to the approach provided by
draft-ietf-tls-cert-abridge (I see that S 7.5 provides
a comparison of these mechanisms, but I'm not going to get
into detail in this message).
2. It allows clients to safely force the server to offer a PQ chain
even if the client actually is type (3). Normally it wouldn't be
safe to only advertise PQ algorithms in signature_algorithms, but
if the server advertises a PQ TA, then the client can safely
provide only that TA in the ClientHello while offering a wider set
of TAs to other servers. This can also be used on the client
side to measure PQ support on servers.
Have I missed other important value propositions for TA for the PQ
transition?
Thanks,
-Ekr
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
