Not addressing your main question, I'd like to refine your sketched migration path for PQ certificates.
On the negative side, I think it's not clear whether we'll reach 4 (clients stop advertising traditoinal algs) when the CRQC arrives: there could well be sufficiently many servers that don't support PQ EE certs yet. On the positive side, I think we might be able to get more security than you suggest before 4. At some point in the hopefully not-too-distant future we can have browser root programs demand that each trusted CA also offers full PQ chains and include PQ SCTs even on traditional certificates. A server that support PQ EE certs would then install two certificates: Ia. One traditional EE cert with traditional chain. Ib. One PQ EE cert with PQ chain. It chooses the certificate based on whether the client supports PQ. A server that does not support PQ EE certs would install a specially-issued *transitional *traditional EE cert with both a traditional and PQ chain. It's important that this *transitional* traditional EE cert is different from the one used in the full traditional chain, and is not issued by default: it signals that the server for the cert does not support PQ. (*) Now, browsers wouldn't accept fully traditional chains, but they would accept these transitional traditional EE certs, which come with PQ SCTs and a PQ chain. For PQ security, server operators need to watch CT and check if such transitional traditional certs are issued for their domains (as they should watch for regular misissuances.) There are quite a few bumps in the road: 1. Unmodified servers might not like the big PQ+trad double chain. 2. Middleboxes/clients might not like the big PQ+trad double chain (as we've seen some evidence of). 3. Browsers need to wait for every last trusted CA to start offering these chains, and for every last traditional EE to expire before enforcing (*). On Sat, Feb 1, 2025 at 7:02 PM 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? > > 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
