On Sat, Feb 1, 2025 at 10:02 AM Eric Rescorla <e...@rtfm.com> wrote:
> 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? > For the first value proposition of TAI allowing servers to elide intermediates, I see this value proposition as being wider than just intermediate elision (which both TAI and draft-ietf-tls-cert-abridge could do; I’m not going to compare the effectiveness of those two approaches for intermediate elision). The setup of the PQ rollout scenario described here assumes that when a CA operator creates a new PQ root, it cross-signs it with a classical CA cert. What’s needed from a PQ transition is a way for a server to know whether to send a classical (RSA/ECDSA) cert chain or a PQ cert chain to a PQ trust anchor. A transition plan that relies on a cross-sign (resulting in a server sending a PQ cert chain anchored by a classical root of trust) results in wasting excessive bandwidth for no security benefit, and such a plan is poorly designed. Although TAI can be thought of as eliding this cross-sign, it is more powerful than just that. This value proposition that TAI offers for the PQ transition is that it does not force the transition to rely on cross-signs. An additional value proposition that TAI offers is for PQ PKIs that don’t look like X.509 or where cross-signs aren’t possible. For example, draft-davidben-tls-merkle-tree-certs uses short-lived trust anchors, so some form of trust negotiation is needed for them to be usable - today’s strategy of waiting for ubiquity does not work. While it is possible for every non-X.509 PQ PKI mechanism to define its own trust negotiation mechanism, this need seems like a common "narrow waist" of the hourglass. On one side of the trust negotiation waist, we have different algorithms and other non-X.509 PKIs that can use it to negotiate trust (similar to different application protocols running over TCP/IP), and on the other side are client trust stores expressing different sets of trust anchors (similar to different physical layers TCP/IP runs on). > > Thanks, > -Ekr > > > > > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
