]> Mozilla

ietf@dennis-jackson.uk

Security Transport Layer Security This document considers proposals to enable the negotiation of trust anchors in TLS. It makes three basic arguments: that trust negotiation is not helpful in addressing the problems it claims to address, that trust negotiation instead comes with material harms to the critical trust infrastructure of the Internet, and that the proposed mechanisms for deploying trust negotiation are unworkable. This draft goes on to discuss simpler and more effective solutions to these problems. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Transport Layer Security Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction For as long as TLS has been used on the web, web servers have been restricted to belonging to one PKI which must satisfy the requirements of every client, or at least as many clients as possible. This constraint has defined the architecture of the web for the past two decades, leading to the consolidation of community, architecture, standards and process in the singular 'WebPKI' as we know it. Trust Anchor Identifiers is a recently proposed draft which enables websites to participate in multiple PKIs through the introduction of trust anchor negotiation. The stated motivation for this proposal is two-fold. For website operators, trust negotiation is proposed to make it easier to maintain compatibility with a diverse range of clients, particularly older legacy clients without up to date root stores. For root program operators, trust negotiation is proposed to enable improvements to the security of their clients. This draft considers TAIs proposed use cases for trust negotiation (). It finds that none of the proposed use cases for improving security stand up to scrutiny. Further, that trust negotiation substantially alters the power dynamics of the WebPKI in way that will most likely lead to negative outcomes for users and website operators. It also identifies trust negotiation as enabling a number of meaningful abuse scenarios. The conclusion of this section is that trust negotiation is not a desirable feature to realize in TLS, regardless of the underlying design or implementation. The draft goes on to consider the high level design described in and its suitability for deployment (). It concludes that the necessary investments and integrations to deploy it are unworkable for the vast majority of clients and servers. This makes the use of trust negotiation for the post-quantum transition deeply unattractive, as well as further undermining the claimed use cases for security and compatibility. This draft concludes in by considering simpler, easier to deploy and more targeted solutions that can enable the post-quantum transition and reduce compatibility challenges for large website operators, without causing unacceptable harms or systemic risk.

The Problem Statement At the TLS interim on October 1st, a problem statement was posed to the meeting:

• Avoid client trust conflicts by enabling servers to reliably and efficiently support clients with diverse trust anchor lists, particularly in larger PKIs where the existing certificate_authorities extension is not viable.

This problem statement is supported by two different motivations. Website operators are interested in compatibility with as broader set of clients as possible. Meanwhile, clients, or really their root program operators, benefit from differentiation and deploying new technology. Although these two perspectives are unified by the abstract framing of the problem statement, it does not follow that a proposed solution will be equally effective for both goals. In fact these two perspectives have often been opposed, with the differentiation and evolutions driven by root program operators in turn necessitating investments and ongoing compliance obligations for website operators. Consequently, its critical to evaluate both perspectives independently, which is the approach taken throughout this document.

What can Trust Negotiation do for the WebPKI? This section examines the use cases for the negotiation of trust anchors ('trust negotiation') which have been proposed in . The use cases are grouped into three distinct themes: improving root program operations, transitioning to post-quantum cryptography and handling conflicting client requirements. The analysis in this section is design-agnostic and assumes that clients and servers have some abstract mechanism to enable clients to signal which trust anchors they support and servers provide the appropriate certificate chains.

Trust Negotiation and Root Program Security Trust Anchor Identifiers draft claims that trust negotiation can improve the operation of root programs and in doing so, improve the security of clients. Unfortunately, these claims are based on statements that ignore already widely deployed solutions and ultimately give a misleading picture of how root programs work today.

Adding CAs In Section 7.1 of TAI, the draft claims:

• Without [trust] negotiation, the authenticating party is limited to its relying parties' intersection and must wait for every supported relying party to be updated [with the new root CA] before the transition even begins

This is a false statement. For many years, the WebPKI has used cross-signed certificates to enable new roots to be used by websites before older relying parties were updated. A cross-signed certificate when one root key is used to sign another root or intermediate key. In this case, when an older CA uses its ubiquitously trusted root CA to sign a newer CA's root key. This enables older relying parties and newer relying parties to trust the same certificate chain, even when the older party is unaware of the new root. This system is ubiquitously supported and in widespread usage by CAs today. Cross-signing is essential part of root program operations and foundational to the existence of many CAs:

• Scott Helme has a blog post explaining cross-signing and its essential role in the creation of Let's Encrypt .
• Certainly, the CA owned by Fastly, currently operates on the basis of a cross-sign from GoDaddy which is used to serve Fastly's website. Without this cross-sign, Fastly's website would be inaccessible on Windows machines, as Microsoft's Root Store does not currently include Certainly's Root CA certificates .
• Google Trust Services, one of the largest CAs in the world, also uses a cross-sign to maximize backwards compatibility .

Cross Signing is also detailed extensively in in this academic survery and in online discussions of root program operations . The primary challenge in the use of cross-signing is that the new CA must arrive at a contractual agreement with an existing CA to grant the cross-sign. As the existing CA is vouching trust in the new CA and considered responsible for them, this typically involves extensive disclosure, vetting and a business agreement. Whilst painful for the new CA, this level of enhanced vetting, in return for being retroactively trusted by existing clients, is critical to the security of the overall ecosystem. As with any commercial relationship between competing businesses, there is the possibility of anti-competitive behavior or otherwise exploitative agreements to the benefit of the incumbent. Root Programs work to mitigate this by maintaining a healthy pool of older ubiquitous CAs to ensure an efficient marketplace. Trust Negotiation does not meaningfully change this situation. If a website wants to be able to serve older clients with an out of date root store, the website operator has no choice but to obtain a certificate chain which is ultimately signed by some CA that those clients trust, whether through a cross-sign or through a certificate chain directly signed by the older CA. Both cases require a commercial agreement with the same parties.

Removing a CA The TAI draft goes on to propose that trust negotiation can make it easier to remove CAs:

• When CAs are determined to be untrustworthy, relying parties must remove them to mitigate the risk to user security. Over time, this shrinks their intersection with older relying parties. Without [trust] negotiation, the result is authenticating parties have fewer and fewer CA choices available. (Section 7.2 of )

This observation is also false and the overall picture given is misleading. Firstly, this use case leaves out critically important context, which is that this intersection is so large as to not be a factor in CA removals. As an example, we consider Android's Root Store, as until 2023, Android was the only major OS to not receive automatic root store updates and so has become notorious for the number of stale clients. However, even for Android, the number of Root CA certificates in the overlap between the newest and oldest devices is more than large enough .

Android Version	Codename	Release Date	Shared Roots with latest Android
4	Ice Cream Sandwich	2011	37
5	Lollipop	2014	60
7	Nougat	2016	74
11	Red Velvet Cake	2020	100

Further, these figures are a substantial under-count because they only consider matching roots directly included in both root stores and don't consider root certificates which are trusted because of a cross-sign. For example, modern CAs like Google Trust Services, Amazon Trust Services, and Certainly, all of which were established long after the release of Ice Cream Sandwich in 2011, are still trusted on these old devices through a cross-sign but are not counted in these figures. Secondly, because of the cross-signing system, the intersection between new and old clients does not strictly shrink. The older clients have fixed root stores. When any of these older roots produce a cross-sign with a newer key, the intersection between new and old clients grows, rather than shrinks. Even when newer clients remove the older root, they are still happy to trust certificate signed by the newer root, regardless of the presence of the older root's cross sign. More generally, the idea that trust negotiation can make it easier for root programs to remove a CA is flawed because its not technical problems that impede CA removal, but non-technical challenges. Firstly, as a root store distrust is a life or death decision for a CA, a CA at risk of being distrusted will try all available means to apply pressure to a root program operator (including legal, commercial and regulatory avenues). This challenge cannot be solved by technical changes to the TLS handshake. The second barrier is that root program operators must engage in a game of chicken {} with the website operators that rely on a to-be-distrusted CA. If root program operators distrust a CA and website operators don't switch to another CA, then those websites will become unavailable for clients of that root program. This can lead to delays when website operators are slow to transition away, which was a serious problem in the distrust of Symantec . However, the Symantec distrust took place in a WebPKI that looked much different. During the Symantec distrust, automated certificate issuance was practically unknown, TLS certificates typically lasted 5 years and were expensive to boot - all powerful factors in slowing the transition. Since the arrival of ACME, free certificates and shorter lifetimes, the friction for website operators to switch has dropped substantially. Root Programs have also introduced the ability to gracefully sunset trust in a CA, through mechanisms like Distrust-After , which bypasses the game of chicken with website operators. This process has recently been enhanced with SCT-Distrust-After, as pioneered by Google Chrome , which provides greater security during the distrust period. As a concrete example, root programs like Mozilla and Google Chrome recently distrusted Entrust which was previously one of the top 10 largest CAs . This transition has been smooth and unremarkable for both website operators and users.

Key Rotation The final root program operation that the TAI draft claims to improve is a key rotation process for root certificates:

• Without trust anchor negotiation, authenticating parties cannot switch to the new root as long as any supported older relying party requires the old root. That, in turn, means relying parties cannot distrust the old root, leaving them vulnerable. (Section 7.3)

This statement is also false. In fact, roots are already rotated periodically using the cross-signing process described in . Here, the cross-signing process is even smoother, because the same CA controls both the new and old root key. This practice has been widely used for many years to carry out root key rotations and is the standard practice of CAs today. Root Program operators are also able to unilaterally reduce trust in long-lived root keys if they so desire. Rather than trust the long-lived root keys, they can instead pin their trust to the shorter-lived intermediate CA keys which rotate much more frequently. These intermediate CA keys are publicly listed in the Common CA Database and required to be published there before being used to sign certificate chains. Clients can be programmed to fallback to trusting the longer lived root certificates if their list of intermediates becomes stale (similar to how CT logs are handled today). As consequence, trust negotiation also has nothing to offer for this use case.

Trust Negotiation for Post-Quantum Certificates puts forward several ways in which trust negotiation could benefit the transition to post-quantum.

Root Ubiquity and Compatibility In Section 7.1, the TAI draft claims:

• Post-quantum-capable relying parties may be detected with the signature_algorithms and signature_algorithms_cert extensions. However, this relies on all post-quantum CAs being added at roughly the same time and that they are sufficiently interchangeable to be negotiated with these extensions. Trust anchor negotiation directly addresses this problem and allows for both gradual and possibly heterogeneous deployment of post-quantum CAs across relying parties.

This claim is also false. Cross-signing (described in ) works just as well when the two root keys are of different types as when they are of the same type. Signing a new PQ with an older classical signature is technically no different from signing a new ECDSA root with an older RSA root, as many CAs have done. Using cross-signing enables each CA to mint new PQ Roots as and when they wish. As modern clients already have nearly identical lists of trusted classical CAs, these cross-signs allow all clients with PQ support to consume the new PQ chains without compatibility problems. It is reasonable to ask whether signing a post-quantum root with a classical cross-sign in some way damages or weakens the security of the certificate chain. Happily, it does not. If the certificate chain is consumed by a client which trusts the new PQ root, then the client will not even bother to check the classical cross-sign and instead consider the chain to be fully post-quantum. If the same chain is consumed by a client which supports PQ signatures, but is unaware of the new PQ root, then it will consume the classical cross-sign and receive only classical authentication, which is the best outcome possible when the client does not have the new PQ root. This process has been further discussed on the TLS mailing list

Intermediate Suppression Section 7.5 of goes on to propose that trust negotiation could be used to avoid the need to deliver intermediates certificates to clients, which would be valuable for the PQ transition given the size of post-quantum cryptographic primitives. This is a use case that trust negotiation can actually address and so the proposed design is evaluated for deployability in and then compared to the existing alternatives in .

Future PQ Experiments Merkle Tree Certificates is a draft proposing a new post-quantum authentication method for TLS which shsares a number of authors with . Although the TAI draft does not reference the Merkle Tree Certificates draft, the MTC draft has been updated to depend on TAI and so it is briefly discussed here. As a premise, MTC is an interesting proposal. However, it has seen little discussion and has many open questions. In particular, the transparency properties it currently provides are much weaker than those of the existing Certificate Transparency ecosystem. Its reliance on a centralized provider for both security and availability is also problematic. A further issue is that several new post-quantum signature schemes with much smaller sizes are still finishing the standardization process (e.g. FN-DSA / Falcon, and the NIST Additional Signatures competitors) and their deployment would make the return on investment of schemes like MTC marginal if not negative. Finally, MTC as a design has no actual need for a dependency on trust negotiation or TAI, and so the question of whether to enable trust negotiation or adopt TAI, is largely independent of the future of MTC.

Trust Negotiation and Root Program Divergence The final set of use cases for trust negotiation proposed in concern allowing root programs to diverge and clients to enforce conflicting policies. Enabling divergence between the major root programs was stated as a 'motivating example' in the Chrome presentation at the interim and in more guarded language in the draft itself:

• An authenticating party may need to support relying parties with different, potentially conflicting requirements. (Section 7.6)

Can divergence improve security? The draft suggests that if root program requirements can diverge, this will allow some clients to enforce stronger security requirements, because tension between different use cases is blocking security improvements. This is not the case and in fact there are no proposed security improvements that are being by root program disagreements or would be unlocked by enabling root program divergence. For example, the TAI draft states:

• In contexts where online revocation checks are expensive, unreliable, or privacy-sensitive, user security is best served by short-lived certificates. In other contexts, long-lived certificates may be more appropriate for, e.g., systems that are offline for long periods of time or have unreliable clocks. (Section 7.6)

In fact there is already a standardized TLS extension which enables some clients to negotiate shorter lived certificates whilst allowing others to use longer lived certificates which has been supported in Mozilla Firefox for several years. In general, security requirements are ultimately additive rather than conflicting, so it is unclear why divergence would ever be necessary in order to improve security. The other security improvements shipped to the WebPKI over the previous decade have not required divergence, indeed, they have typically benefited from convergence and unified support to encourage adoption. For example, security requirements might require more information for authentication to be placed in a certificate (like SCTs used in Certificate Transparency), reduce the number of parties which can issue certificates, or require shorter certificate lifetimes are all additive security requirements. Each root program is able to adopt these stricter requirements individually, indeed as many have done so. Over time, as the ecosystem shifts, these security requirements are transferred into the CabForum baseline requirements, through a formal voting procedure , which standardizes the consensus between the WebPKI Root programs and other stakeholders. This is an effective one-way ratchet for improving the security of web users. In reality, the largest constraint on shipping new security improvements in the WebPKI is not the expectations of other TLS clients or other root program requirements, but the level of investment that website operators are willing to make in terms of security. As it stands, the reluctance of website operators and enterprise vendors to invest in automated certificate lifecycle management solutions like ACME is what currently prevents root programs enforcing shorter certificate lifetimes.

Empowering Root Programs Although trust negotiation is ineffective for improving security, it is effective at changing the power dynamics of the WebPKI. The current inability of websites to service users from different PKIs, means that the root programs of popular clients are incentivized to align their requirements. If a root program were to diverge in its requirements, websites would be forced to choose between supporting the consensus requirements or the diverging root program's requirements. As websites naturally want to be as accessible by a wider pool of users as possible, they will follow the consensus requirements, which in turn motivates root programs to avoid issuing conflicting or diverging requirements. Trust negotiation, in enabling clients and websites to negotiate different certificates, reverses these incentives and so shifts the balance of power in this system. If Trust negotiation were widely supported, then root programs could issue conflicting requirements and instead expect website operators to obtain multiple certificate chains in order to satisfy all of their clients. Enabling conflicting requirements, rather than simply additive ones, would ultimately enabling the WebPKI to shift from a well-functioning commons with multi-stakeholder governance to a fragmented patchwork of private fiefdoms, each dominated by a root program operator.

Burdening Website Operators This shift in power towards root program operators would be deeply counterproductive to the goals of website operators, who largely wish to minimize the disruption and complexity of compliance with root program and client requirements - which implies a preference for consistency and uniformity amongst clients. Today, website operators only need to establish a relationship with a single certificate authority, which is easily done on the basis of popularity and service offered. Even the largest websites looking for maximum compatibility today are still able serve a single certificate chain from a single partner CA to all of their clients. Trust Negotiation reverses this situation. As each root program can diverge and evolve fully independently, the website operator needs to constantly track these changes and transitions to make sure they are partnered with sufficiently many CAs to retain widespread support. This is a strict increase in complexity and the number of transitions that the website operator has to manage. Ultimately, this pushes the pain and complexity of avoiding conflicts from the small number of root program operators and CAs, who are well positioned to bear it and moves it down to to individual website operators. This means asking orders of magnitude more people, who are less expert, to carry out more complex tasks in order to maintain the same compatibility and support they already have today. The website operators have little leverage in this situation, they either find a suitable certificate chain for each conflict, or they lose those clients of that root program.

To what end? No one can claim infallible foresight about how this change in power dynamics would impact as complex a system as the WebPKI. For the existing root program operators, we would of course hope that they would continue to prioritize user security over other incentives. However, enabling root programs to diverge also incentivizes the establishment of new root programs and this has been noted as a possibility by one of the authors of :

• One of the (unstated, and perhaps we should state it clearer) goals of trust expressions is to allow for new root programs to be created.

As discussed in , there are no substantive proposals for how divergence or a new root store would improve security. Unfortunately, the most obvious motivations for establishing a new root store would be deeply negative for users.

Money The majority of product and device manufacturers take the easiest path with respect to security, that is, they ship the defaults of whatever technology is readily available. Today, the default is the WebPKI and complying with the WebPKI's requirements is typically seen as much easier than establishing your own root program. However, if alternative root programs that put less weight on security were readily available, they would present as compelling options for those less security conscious device or software manufacturers. These alternative root programs struggle to exist today, because websites are forced to choose which PKI to participate in, but of course trust negotiation lets them participate in multiple without issue. In the WebPKI, security improvements have been driven forwards by the high concentration of browsers who are motivated to improve security in order to widen usage of the web. However, alternative root programs are likely to follow different dynamics depending on who governs them and consumes. Absent concerned force of motivated and responsible entities to drive improvements, these alternative root programs are most likely to stagnate rather than evolve, especially if their membership is self-selects for those less willing to invest in security. After all, security remains a low priority for many commercial entities and its unlikely that most commercial operators of a new root program would put the same emphasis on security that browsers do. Unfortunately, users are relatively insensitive to the security of their devices, especially opaque intangibles like root program policy and so the economic incentives towards cost-cutting are likely to dominate. It also goes without saying that whilst this would not directly impact the security of browsers, it would impact the websites forced to participate in these less secure ecosystems (through client's choice of which to adopt) and it would most definitely impact users, whose digital security is defined by the weakest device or software product they depend on.

Control The other primary motivation for establishing a root program is control over the network communication between clients and servers using it. To this end, some governments have previously established their root certificates under their control and proposed to have them distributed to browsers and other clients within their territory, for example , and . These root certificates can then be used to intercept, survey and censor network traffic within their borders. Recently, some governments have engaged in efforts which would achieve a similar outcome by less direct means . Rather than mandate trust in a particular root certificate or a government-operated CA, a government establishes their own root program which selects trustworthy domestic CAs. The domestic CAs have an obvious commercial incentive to encourage these efforts. The government then pushes for client and server adoption of its domestic root program which ultimately enables interception and surveillance but can be dressed up as a legitimate initiative, with a ostensibly valid political objective, e.g. to achieve digital sovereignty, divest from big tech, build a local trust economy, and so on. One of the most powerful arguments against this approach is that in the current system it can serve no legitimate purpose because it is impossible for websites to adopt these certificates without becoming unavailable to users who do not have the roots installed. As it is extremely unlikely that any non-domestic user would ever adopt these roots, consequently websites are forced to choose between using a WebPKI CA and the ubiquitous trust it enjoys, or a domestic CA which means blocking the vast majority of non-local users or non-compatible devices. This means that a domestic PKI within the WebPKI's current architecture is largely a vanity project which offers few benefits. Deploying trust negotiation resolves these issues. Just as it enables the existing root program operators to diverge, or new commercial root programs to become established, it also resolves the issues that governments face running domestic root programs. Rather than having to try to force websites to solely use a domestic CA with limited deployment, governments could now ask (or require) websites to deploy certificates from a domestic CA in addition to their existing WebPKI CA. This in turn enables a gradual transition of client devices towards the domestic PKI. An option, after sufficient incubation of a domestic PKI and only available to the largest countries or federations, would then be to supplant the WebPKI entirely. As well as requiring a set of designated root certificates to be distributed, the government would also actively discourage the distribution of other non-approved root certificates to domestic clients. If carried out, this would create a PKI-based splinternet which would be useful not only for intercepting, surveilling and censoring the individual connections of users, but would enable pro-active control of connections, where websites would need to apply for suitable certificates to become available to those stuck in the splinternet (e.g. meeting the necessary regulatory standards for identification and 'wholesomeness'). Without trust negotiation, this kind of divergence would mean cutting oneself off from the Internet entirely. An idea which has been proposed and partially experimented with in some countries like Russia, China and Iran, but even these countries have shied away from the economic costs of such taking such a drastic step. Here too, trust negotiation offers a technical solution, enabling this divergence without the economic harm of total isolation. More succinctly, whilst trust negotiation might be envisioned to enable either Chrome and Firefox or browsers and IoT devices to negotiate different certificates. Trust negotiations works just as well to enable residents of different countries to negotiate different certificates, there is no technical difference between these scenarios and it is inarguable that trust negotiation solves some of the most substantial technological barriers that prevent these scenarios. Whether or not these observations meaningfully changes your beliefs about the likelihood of these outcomes is a much more subjective and nuanced question. If you believe that these outcomes are unfortunately inevitable or thankfully impossible, then even substantial changes in the technical landscape matter little. However, there is good evidence that in fact the political situation is quite unsettled and even small efforts can lead to substantial differences in outcomes .

Alternative paths to Abuse It shouldn't need to be said, but nobody involved in this discussion believes the outcomes described in the previous section would be positive or acceptable. However, it has been argued that widespread deployment of Trust Negotiation would not change the probability of these negative outcomes. The argument runs broadly as follows:

• The security of clients reduces to which roots they have in their root store.
• Governments can already pass laws to force clients to use certain roots.
• Trust Negotiation does not affect the probability that such a law is passed.

This argument fails in the last step. Whether or not a law is passed is a function of what it achieves and how it can be justified. Trust Negotiation creates the technical architecture for the creation and operation of divergent root programs, resolving key technical barriers and enabling persuasive justifications. A second line of argument is instead that governments could deploy trust negotiation themselves either directly or through alternative means such as:

• Using national signature algorithms, advertised in the TLS client hello, as a proxy for negotiating trust.
• Using the certificate_authorities extension to enable a 'small' domestic root store.

As theoretical technical designs, the first two approaches could be used to achieve a limited form of Trust Negotiation. However, both are practically blocked today because clients and servers would need to have new code shipped to either support the national signature algorithm or to support the certificate_authorities extension in the Client Hello. The sheer diversity of clients and servers in the world today and the difficulty of updating their TLS libraries is a formidable barrier to this outcome. At the end of the day, it is running code that matters, not theoretical designs and that is why we have to weigh the risks of deploying new technology, because as a community we have the power to change that code in a way that is extremely difficult, if not impossible, for governments.

The design and deployability of Trust Anchor Identifiers This section considers the design and deployability of the Trust Anchor Identifier design proposed in draft-beck-tls-trust-anchor-ids-03 . As with any draft at the pre-adoption phase, the draft need not present a complete solution, however, it is critical to understand how the external dependencies and high level design of the draft impact its deployability and fitness for purpose.

Overview Unfortunately, TAI is not an easy design to deploy. For both clients and servers, it requires deep and invasive changes to both TLS libraries and the client and server applications that depend on them. For clients, this includes necessary integrations with DNS resolvers (whether mediated by the application or the TLS library), new stateful retry mechanisms and error handling code and a deprecation of existing APIs which allow for post-validation pinning. For servers, TAI requires existing application mechanisms for providing TLS certificates to be deprecated and complex and ongoing automated DNS changes which need to be integrated with automated certificate management solutions. These changes cross many existing software boundaries and touch many parts of the ecosystem and ultimately limit the deployability of this design to only the most capable clients and servers who are willing to make the necessary investments and already integrate the necessary dependencies, essentially browsers and CDNs. The limited deployability of TAI further undermines many of the proposed benefits. From the perspective of website operators, browsers are already highly homogenized in their behavior and so trust negotiation with them alone offers little room for improvement but could lead to divergence between browsers, driving up their operational burden. For root program operators, the situation is even worse, since any tightening of security policy reliant on TAI requires near universal deployment by website operators, who have historically been the blocking factor in most new TLS technologies. The limitation of TAI to highly capable and integrated parties like browsers and CDNs is especially problematic for future root program transitions. For example, predicating the PQ transition upon a design like TAI would leave behind the vast majority of clients and servers who are unable to adopt it. This harms not only users of clients which couldn't make the transition, but also users TAI-capable browsers who cannot negotiate PQ cryptography with websites not using a major CDN.

The Design of TAI Draft-beck-tls-trust-anchor-ids-02 has a simple design. Every root certificate is assigned a short OID as an identifier. Servers can obtain one or more certificate chains, each of which terminates in a single root certificate and they advertise the corresponding identifiers for their certificate chains in a DNS record. The draft requires servers to keep this information up to date, which means in practice updating these DNS records whenever their certificate chains change - e.g. because new certificates have been acquired, or because existing certificates have been revoked or have expired. Clients can fetch these DNS records, inspect the advertised identifiers against their own root store and then use an extension in the ClientHello to ask the server to send a particular certificate chain. This mechanism relies upon either the client application being aware of this draft and providing the necessary information from DNS to the underlying TLS library, or the TLS library having its own mechanism for fetching information from DNS. Servers also provide a full list of their identifiers to clients in their EncryptedExtensions message. This allows for a more expensive recovery path (a full additional handshake) for clients that do not have the necessary DNS information, or where the DNS configuration is incorrect. Clients can retry the connection based upon the list of identifiers from the EncryptedExtensions message. This requires changes at the application level (to handle the retry), as well incurring a substantial performance and latency hit (especially when using PQ cryptographic primitives). It is important to understand that the DNS aspect of this flow is essential and not optional. Trust anchors are expected to have roughly 6-byte identifiers and client root stores include between 150+ anchors (just roots) and 2000 (including intermediates for intermediate suppression). This means that clients cannot advertise their full root store with this extension, as it would inflate their client hello by between 900 and 12,000 bytes.

Server-Side Deployment Challenges The dependency on DNS and the requirement for the server's TLS certificates and DNS records to be managed automatically and by the same component is challenging for real world deployment. Firstly, DNS configuration and APIs are non-standardized and vary widely between locally managed DNS servers, cloud providers & DNS registrars - if they are even available at all. Secondly, sever's existing DNS configurations are similarly diverse and so it is challenging, if not impossible, for an automated tool to offer a correct configuration out of the box for anything but the simplest single-server deployments, especially considering common uses cases where multiple TLS servers share the same domain name and DNS records (e.g. round-robin DNS, multi-CDN deployments). As a result, TAI will likely require expert configuration and continued attention whenever changes are made to a webserver's configuration. Thirdly, the secrets used to authenticate DNS configuration changes are often more valuable than TLS certificate private keys to attackers and so are discouraged from being stored on webservers at all . TAI also requires changes between server-side applications and their underlying TLS libraries. Existing libraries typically provide APIs to allow the application to select which certificate is used for a given connection (e.g. based on SNI). TAI will require either the applications to become aware of TAI and use it to guide their selection, or the existing APIs to be deprecated so that the library can handle the choice of certificate. These kinds of investments are easier to make for large CDNs who have the necessary technical expertise and likely already have in-house management systems for their TLS certificates and DNS records, but even then are substantial undertakings requiring invasive surgery to critical components. For the vast majority of website operators, these kinds of investments are completely unrealistic and would require a substantial increase in complexity in existing TLS libraries and ACME clients. As a practical example, consider the fate of OCSP-Must Staple , which was a revocation mechanism championed by all major browsers as a substantial security, privacy and performance boost over traditional revocation mechanisms. However, it relied on TLS servers periodically making a HTTP request to a CA, caching the result and offering it in the TLS handshake to clients. Unfortunately, even this design, which is much more simple and requires much less complex integrations than TAI, proved too complex and expensive for website operators to adopt and has since been abandoned .

Client-Side Deployment Challenges TAI depends on the TLS library being provisioned with the necessary information from DNS. This requires either the application being aware of TAI, making these requests itself, and so passing them on to the TLS library, or the TLS library being integrated with a DNS client. The former requires applications to opt-in to TAI and invest in performantly fetching the necessary records. The latter requires the TLS library to integrate with a DNS client. Changes are also required to the existing APIs between TLS libraries and clients to ensure the Trust Anchor Identifiers in the Client Hello have the correct semantics. A typical flow for applications today is to rely on the TLS library to validate a certificate, then afterwards to inspect the certificate chain via the libraries API to perform some additional verification (like certificate pinning as described in the TAI draft). However, existing APIs do not allow the TLS library to know whether the application is going to do this at the time it sends its client hello, making the Trust Anchor Information contained within it unreliable unless the application opted in. The retry flow also requires changes to the applications using TLS libraries, so that they understand the resulting error code from the initial TAI failure and know to restart the connection with the provided retry information. Ultimately, TAI requires a deep integration between the client application, the TLS library, the DNS resolver and the root store in use (whether operating system or application provided). Browsers are well positioned for this integration, as most already include all of these components, but the picture for non-browsers is bleak.

Interaction with Encrypted Client Hello TAI and ECH share similar aspects of their design, both relying on a HTTPS resourced record to discover information about a server and using a retry mechanism which requires a fresh connection to the server. Unfortunately, the proposed TAI extension and ECH compose together poorly. If the ECH Config and Trust Anchor Identifiers for the public name and inner name are stale, clients are required to make 4 consecutive handshakes before they can successfully connect:

1. An initial connection with a stale ECH config and stale Trust Anchor Identifiers. ECH is rejected and there's a certificate error. The client learns the correct Trust Anchor Identifiers for the public name but must throw away the unauthenticated ECH Retry information.
2. On the second connection, the client has the right TAIs and learns a correct ECH Config through the retry extension.
3. On the third connection, the client has the right ECH config, but still has stale Trust Anchor Identifiers for the inner name and so the connection fails.
4. On the fourth connection, the client can now connect successfully.

Consequences of a limited deployment For TAI to be effective, it necessarily needs to be deployed by both the client and server. The limited deployability of TAI is a substantial issue, as it makes many of the proposed use cases unworkable in practice (in addition to the other issues discussed in ). For example, consider the proposed use case of easier CA removals for root program operators which was evaluated in . Obviously, the root program operator needs widespread TAI support deployed in their clients and so is likely a web browser provider. However, the root program operator is also dependent on the web servers which use the distrusted CA supporting TAI in order to make use of it. Given the unpredictability of which websites are impacted by a distrust event and the stated goal to speed up the process, this assumes that either TAI support is ubiquitous or the affected websites can deploy it quickly, but this is deeply unrealistic given the deployment challenges identified. Another example would be the use of TAI for intermediate suppression in order to support post-quantum authentication between clients and servers. We want the transition to post-quantum primitives to be practical for as many clients and servers as possible and the deployment challenges of TAI would be a serious obstacle. Whilst it's typical for technologies to arrive unevenly, with browsers and CDNs often going first, it is critically important that the rest of the ecosystem be able to follow. If enough websites couldn't follow, then even users of up to date browsers would suffer as the transition to PQ stalls. If enough non-browser clients couldn't follow, then not only would users and websites suffer from the stalled PQ transition, but the outcome could well be the bifurcation of the entire ecosystem, leading to prolonged stagnation and insecurity for non-browsers and harm for users. Website operators capable of deploying TAI (e.g. large CDNs) and wanting to use it for compatibility are reliant on their clients introducing support for it as well. As identified earlier, deployment would be largely limited to browsers. This substantially limits the benefit of TAI to website operators, because browser's root stores and TLS behavior is highly homogenized. Meanwhile, the long tail of non-browser clients with less well understood root stores and policies, who cause the most compatibility issues, would be the least likely to go out of their way to invest in TAI support in their applications and libraries. Put another way, any client willing to make the necessary investments and integrations for TAI, has likely already invested in automatic root store updates and modern TLS compatibility, minimizing the benefit to website operators. The net effect for website operators is that TAI would enable divergence in the currently homogenous population of browsers, but do nothing to mitigate compatibility problems with the long tail of non-browser clients.

The Path Forwards evaluated the proposed use cases for Trust Negotiation and concluded that none of the proposed use cases for improving security stood up to scrutiny. It also identified the ecosystem impacts of trust negotiation as deeply negative for the Internet due to the transfer of complexity and responsibility from root program operators to website operators and the risk of fragmentation and abuse. The conclusion of this section is that Trust Negotiation at scale is not a desirable feature to enable in TLS, regardless of the underlying design or implementation. {#Deployability} considered the design of TAI specifically and evaluated its suitability for deployment at scale. TAI requires substantial investments to deploy and deep integrations between applications, TLS libraries, DNS and certificate management tooling, along with complex configuration and operational requirements that effectively prohibits deployment outside of highly integrated environments like browsers and major CDNs. These challenges make TAI effectively unworkable for the lone use case that is identified as valuable - enabling a transition to post-quantum authentication through intermediate suppression. Ultimately, attempts to enable trust negotiation are attempts to radically alter the WebPKI and change its underlying architecture. It represents a loosening of constraints on root programs without any clear benefits and several clear risks. Most critically, that it transfers complexity and responsibility from root programs and onto website operators, and that it empowers bad actors to establish their own root programs for their own end. As TAI could only be deployed by browsers and a small number of the largest websites, it would in any case be difficult to justify any increase in complexity for the majority of website operators or risks to the security of web users, in return for unclear benefit to the few individuals to whom the burden of root program management and certificate compatibility currently falls to. The proposed use cases for trust negotiation for intermediate suppression to help enable the transition to post-quantum is the single compelling use case. However, there are several alternative mechanisms that have already been proposed, including one which has already been adopted by the TLS WG, and all of which are much simpler and easier to implement, will not bifurcate the TLS ecosystem between browsers and non-browsers and do not entail the risks of the abuse of trust negotiation. The next section of this draft explores those alternatives and compares them to TAI. The final section of this draft explores more modest solutions to the challenges of website operators trying maximize their compatibility with old clients. These solutions focus on simple efforts to address the underlying issues of visibility, ageing clients and negligent device manufacturers.

Delivering Intermediate Suppression Intermediate Suppression is the goal of removing the size overhead of the CA certificates from the TLS handshake, which is especially important with larger PQ signatures. In fact, a reasonable proportion of websites already omit these intermediate certificates which was historically caused connection errors, and so already motivated clients to find solutions. For example, as the major root programs require all CAs to publish their intermediate certificates in the CCADB ahead of use, and Mozilla distributes a bundle of these intermediate certificates to every Mozilla Firefox client . Other clients use different strategies, for example, Google Chrome, Edge, Safari all use a technique known as 'AIA chasing' which allows them to fetch and cache any intermediate certificates missing from the server's certificate chain . Trust Anchor Identifiers proposes that clients take a similar pre-distribution strategy to Mozilla Firefox and store a copy of the available intermediate certificates, have servers advertise which intermediate trust anchors they use in TLS and then use TAI to have clients request a shortened chain from the server. As discussed earlier, this requires extensive and costly changes to clients, servers and introduces a number of dependencies.

Abridged Certificate Compression Abridged Certificates is a draft already adopted by the TLS Working Group. It is a type of TLS Certificate Compression , similar to existing methods like Brotli or Zstd, but which enables pre-distributed CA certificates to be compressed out of the TLS handshake by mapping each certificate to a 3 byte identifier. Unlike TAI, Abridged Certificate Compression can be deployed by default in the TLS library without application changes, can't break connections or cause retries, is entirely transparent to the application using the library and doesn't impact trust decisions. Further, it doesn't require any DNS integration on the client or server, or other external dependencies. Abridged Certificate Compression has a simple implementation and an extremely small code footprint, needing only to ship a list of certificate hashes (for each intermediate and root in the dictionary) and their corresponding identifiers. On servers, this is sufficient to provide compression. On clients, this is sufficient to detect whether the client's root store includes the necessary intermediates to perform Abridged Compression. Currently, the Abridged Certificate draft currently describes a static versioning scheme, where each listing of compressible certificates is given a specific TLS certificate compression codepoint, new versions of which would be published yearly in line with existing WebPKI practices for root store updates. The dictionary format is designed so that clients and servers can simultaneously support multiple versions of the mapping without redundancy by reusing the same list structure. The draft focuses on WebPKI certificates but is easy to extend to private schemes for enterprise settings or other custom mappings of compressible certificates. Clients and servers can support multiple schemes as needed as this does not impact trust decisions, require external configuration or connection retries. An appendix to the draft also describes an alternative approach which would allow for dynamically versioned dictionaries without the need to use new codepoints.

AIA Chasing with Storage RFC 5280 describes the Authority Information Access Extension for X.509 certificates which describes a URL where the signing certificate can be located. For example, a leaf certificate will contain a URL pointing to the intermediate certificate, which in turn will contain a URL pointing to the root certificate. Many existing clients, including browsers (Chrome, Safari, Edge ), OS Implementations (Windows s_channel, MacOS Secure Transport ) and middleboxes (, ) already support AIA Chasing. If a certificate chain is presented to these clients with an unrecognized signature, the client will look for the AIA extension, download the signing certificate and if valid, use it to complete the certificate chain . This can be used to achieve intermediate suppression by having the client signal the server that it does not need to be provided with intermediates (as described in ). The client will then either validate the certificate chain locally or fetch any necessary intermediates via AIA as required. This fetch is privacy preserving (it does not identify the leaf certificate or the user) and the result can be stored for the lifetime of the intermediate certificate (several years). The adoption of this technique in Chrome on Android in 2016, proposed by Emily Stark and supported by Ryan Sleevi , was justified as "an important aspect of PKI mobility" and "to highlight that it allows for PKI transitions to happen independently, without centralized coordination and management", noting that "some of us believe that AIA fetching represents an important aspect of ecosystem health, and that all PKI clients should implement this for robustness."

Deployment Considerations Both Abridged Certificates and AIA Chasing are much simpler and easier to implement than TAI. Abridged Certificates is small enough and simple enough to be shipped by default in TLS libraries and have no external dependencies or integration requirements. It is entirely transparent to both clients and servers. It does not require any configuration, interaction with DNS or other operational burdens. It can also seamlessly interact with clients with different root stores, with very different supported versions because it does not impact trust decisions. AIA Chasing is more complicated to implement than Abridged Certificates and making a network call or persisting state to short or long term storage may not be viable for all clients. However, it is already widely supported and has ancillary benefits as it can be used to effectively update a client's root store even if the client is no longer receiving software updates. This is because AIA can fetch cross-signed certificates and store them for future use. This does not have any security implications because an attacker can always provide the cross-signed certificate themselves. Both designs have the side-benefit of making offering cross-signed certificates effectively free in the TLS handshake, allowing greater flexibility for servers looking to maximize their compatibility. In this fashion, AIA is slightly easier for server operators since they need only provision a leaf certificate and leave the AIA configuration to the CA. Abridged Certificates is more flexible for server operators but requires them to configure the full chain they want to send.

Reducing the operational burdens for website operators This section proposes approaches for reducing the burden on website operators for maintaining websites compatible with older clients. Recognizing that this is not a problem that impacts the vast majority of website operators, who enjoy a set it and forget it mentality to TLS, these approaches target improvements for the operators of major websites and CDNs.

Automatic Client Root Store Updates Most major browsers, platforms and operating systems, including MacOS, iOS, Chrome, Safari, Firefox, Edge, Windows and most linux distributions provide automatic root store updates for their users and have done so for over a decade. Legislative efforts are also ongoing in the UK and EU to ensure all new devices to come with automatic security updates as a basic condition of sale . A notable outlier has been Android. Until Android 7 released in 2016, Android had no uniform root store, instead relying on each individual device manufacturer to provision their own certificates . Until Android 14 released in October 2023, the system's root store could not be updated without a manufacturer provided firmware update, which was functionally impossible . Since Android 14 released a year ago, root store updates are now available on Android through standard app store updates (e.g. via the Play Store). Consequently, Android has been the primary source of root store compatibility pain for the majority of websites over the past decade, as reflected in blog posts by Cloudflare and Let's Encrypt when they evaluate certificate chain compatibility and transitions . As Android 14 propagates through the ecosystem, currently at around 30% of devices, we can largely put this challenge behind us.

When Automatic Updates Fail Even with the best of intentions and legislative backing, clients will eventually go out of support. As mentioned earlier, AIA chasing offers an effective mechanism for providing ongoing compatibility updates to such clients and would improve the robustness of the WebPKI if it were universally supported. TLS Clients are also aware of when they last received a root store update and some already use it to guide their security profile (example: disabling CT once their list of logs becomes stale). This approach can be naturally extended to provide graceful obsolescence. After a fixed period of time, be it 5 years or 10 years, without security updates, it is deeply misleading to claim to the user or application be able to provide a secure connection. The default behavior of TLS clients in such circumstances should be to always report a certificate validation error and let the application or the user figure out what to do. At the very least, that means that the user will correctly understand that their client is no longer secure (due to all the TLS error pages they will see). A similar effect is likely to happen naturally as the WebPKI shifts to shorter term root certificates (currently 15 year terms). This limit effectively caps the maximum lifetime of a TLS client without updates to at most 15 years, reducing the pressure on website operators to serve these older clients. In extremis, website operators are able to fingerprint TLS clients and decide which certificates to use for a given software version . These granular fingerprints are highly stable and typically identify TLS libraries and their software version uniquely, but even very simple heuristics (like the offered TLS versions) allow for the easy dating of an implementation and it's root store to within a few years. This enables website operators to send suitable certificate chains to extremely old clients, even if no cross-sign to a modern chain exists.

Tools for Website Operators The vast majority of website operators are well served by the WebPKI and understand little of it beyond the need to select a CA and (hopefully) to configure a certificate management solution. However, for the small number of individuals working at larger tech companies with longer term backwards compatibility goals, choosing a certificate authority is more complicated and requires an understanding of historical and contemporary root stores, plus the available cross-signs. This information is available via the CCADB for some root stores but not others and often each root store has a custom format for recording its contents. Providing better machine readable information about root store contents and changes, and how that impacts the compatibility of modern CAs, would be a valuable tool for expert users. Similarly, providing a signalling mechanism for HTTP or TLS clients to convey their root store contents to websites would help major operators evaluate compatibility. Browsers already support Network Error Logging, a mechanism for websites to opt-in to receiving reports about failed connections, which could be easily extended in this direction and would pose a privacy problem provided it did not disclose any user-specific changes. Even major websites are often in the dark about best practices for changing certificate chains and monitoring compatibility through techniques like A/B testing. Tooling and better community support would provide operators with greater confidence in making transitions. Similarly, many lessons were learned by root program operators during misadventures with certificate pinning or shipping client applications without root store update mechanisms in the 2010s. A useful technique to workaround these situations is to separate traffic by domain (e.g. directing particular clients onto per-client and per-version subdomains) which aliased to the primary domain allowing for custom certificate selection if necessary.

Security Considerations This document is almost entirely security considerations.

IANA Considerations This document has no IANA actions.

Informative References Google LLC Google LLC Google LLC Meta This document defines the TLS Trust Anchors extension, a mechanism for relying parties to convey trusted certification authorities. It describes individual certification authorities more succinctly than the TLS Certificate Authorities extension. Additionally, to support TLS clients with many trusted certification authorities, it supports a mode where servers describe their available certification paths and the client selects from them. Servers may describe this during connection setup, or in DNS for lower latency. Google LLC Google LLC Cloudflare This document describes Merkle Tree certificates, a new certificate type for use with TLS. A relying party that regularly fetches information from a transparency service can use this certificate type as a size optimization over more conventional mechanisms with post- quantum signatures. Merkle Tree certificates integrate the roles of X.509 and Certificate Transparency, achieving comparable security properties with a smaller message size, at the cost of more limited applicability. Mozilla This draft defines a new TLS Certificate Compression scheme which uses a shared dictionary of root and intermediate WebPKI certificates. The scheme smooths the transition to post-quantum certificates by eliminating the root and intermediate certificates from the TLS certificate chain without impacting trust negotiation. It also delivers better compression than alternative proposals whilst ensuring fair treatment for both CAs and website operators. It may also be useful in other applications which store certificate chains, e.g. Certificate Transparency logs. Independent Fastly Cryptography Consulting LLC Cloudflare This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tlswg/draft-ietf-tls-esni (https://github.com/tlswg/draft-ietf-tls-esni). In TLS handshakes, certificate chains often take up the majority of the bytes transmitted. This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] Mozilla AWS AWS Cloudflare A TLS client or server that has access to the complete set of published intermediate certificates can inform its peer to avoid sending certificate authority certificates, thus reducing the size of the TLS handshake. The organizational separation between operators of TLS and DTLS endpoints and the certification authority can create limitations. For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the Certification Authority (CA). This document describes a mechanism to overcome some of these limitations by enabling operators to delegate their own credentials for use in TLS and DTLS without breaking compatibility with peers that do not support this specification. Sectigo Google Wikipedia Censys Mozilla Mozilla IETF NIST Digicert smallstep Let's Encrypt Certbot Mozilla Cisco Broadcom BadSSL RPC Department for Science and Technology, UK Gov Google Google Cloudflare Let's Encrypt Cloudflare EFF OONI Internet Society Mozilla Mozilla Internet Society

Acknowledgments TODO acknowledge.