Trust is non-negotiable
draft-jackson-tls-trust-is-nonnegotiable-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Dennis Jackson | ||
| Last updated | 2024-12-20 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-jackson-tls-trust-is-nonnegotiable-00
Transport Layer Security D. Jackson
Internet-Draft Mozilla
Intended status: Informational 21 December 2024
Expires: 24 June 2025
Trust is non-negotiable
draft-jackson-tls-trust-is-nonnegotiable-00
Abstract
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
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://dennisjackson.github.io/draft-jackson-tls-trust-is-
nonnegotiable/draft-jackson-tls-trust-is-nonnegotiable.html. Status
information for this document may be found at
https://datatracker.ietf.org/doc/draft-jackson-tls-trust-is-
nonnegotiable/.
Discussion of this document takes place on the Transport Layer
Security Working Group mailing list (mailto:tls@ietf.org), which is
archived at https://mailarchive.ietf.org/arch/browse/tls/. Subscribe
at https://www.ietf.org/mailman/listinfo/tls/.
Source for this draft and an issue tracker can be found at
https://github.com/dennisjackson/draft-jackson-tls-trust-is-
nonnegotiable.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Jackson Expires 24 June 2025 [Page 1]
Internet-Draft Trust is non-negotiable December 2024
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 24 June 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Problem Statement . . . . . . . . . . . . . . . . . . . . 4
3. What can Trust Negotiation do for the WebPKI? . . . . . . . . 5
3.1. Trust Negotiation and Root Program Security . . . . . . . 5
3.1.1. Adding CAs . . . . . . . . . . . . . . . . . . . . . 5
3.1.2. Removing a CA . . . . . . . . . . . . . . . . . . . . 6
3.1.3. Key Rotation . . . . . . . . . . . . . . . . . . . . 8
3.2. Trust Negotiation for Post-Quantum Certificates . . . . . 9
3.2.1. Root Ubiquity and Compatibility . . . . . . . . . . . 9
3.2.2. Intermediate Suppression . . . . . . . . . . . . . . 10
3.2.3. Future PQ Experiments . . . . . . . . . . . . . . . . 10
3.3. Trust Negotiation and Root Program Divergence . . . . . . 11
3.3.1. Can divergence improve security? . . . . . . . . . . 11
3.3.2. Empowering Root Programs . . . . . . . . . . . . . . 12
3.3.3. Burdening Website Operators . . . . . . . . . . . . . 13
3.3.4. To what end? . . . . . . . . . . . . . . . . . . . . 14
4. The design and deployability of Trust Anchor Identifiers . . 18
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2. The Design of TAI . . . . . . . . . . . . . . . . . . . . 19
4.3. Server-Side Deployment Challenges . . . . . . . . . . . . 20
Jackson Expires 24 June 2025 [Page 2]
Internet-Draft Trust is non-negotiable December 2024
4.4. Client-Side Deployment Challenges . . . . . . . . . . . . 21
4.5. Interaction with Encrypted Client Hello . . . . . . . . . 22
4.6. Consequences of a limited deployment . . . . . . . . . . 22
5. The Path Forwards . . . . . . . . . . . . . . . . . . . . . . 23
5.1. Delivering Intermediate Suppression . . . . . . . . . . . 25
5.1.1. Abridged Certificate Compression . . . . . . . . . . 25
5.1.2. AIA Chasing with Storage . . . . . . . . . . . . . . 26
5.1.3. Deployment Considerations . . . . . . . . . . . . . . 27
5.2. Reducing the operational burdens for website operators . 28
5.2.1. Automatic Client Root Store Updates . . . . . . . . . 28
5.2.2. When Automatic Updates Fail . . . . . . . . . . . . . 29
5.2.3. Tools for Website Operators . . . . . . . . . . . . . 29
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8. Informative References . . . . . . . . . . . . . . . . . . . 30
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 36
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 36
1. 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 [TAI] 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
(Section 3). 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.
Jackson Expires 24 June 2025 [Page 3]
Internet-Draft Trust is non-negotiable December 2024
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
[TAI] and its suitability for deployment (Section 4). 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 Section 5 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.
2. 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. [TLSInterim]
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.
Jackson Expires 24 June 2025 [Page 4]
Internet-Draft Trust is non-negotiable December 2024
3. 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 [TAI]. 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.
3.1. Trust Negotiation and Root Program Security
Trust Anchor Identifiers [TAI] 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.
3.1.1. 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 [LECrossSign].
Jackson Expires 24 June 2025 [Page 5]
Internet-Draft Trust is non-negotiable December 2024
* 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
[FastlyCRT].
* Google Trust Services, one of the largest CAs in the world, also
uses a cross-sign to maximize backwards compatibility
[GTSCrossSign].
Cross Signing is also detailed extensively in in this academic
survery [CrossSignStudy] and in online discussions of root program
operations [SleeviCrossSign].
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.
3.1.2. 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 [TAI])
Jackson Expires 24 June 2025 [Page 6]
Internet-Draft Trust is non-negotiable December 2024
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 [Android14RootStore] 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 [AndroidRoots].
+=================+============+==============+===================+
| Android Version | Codename | Release Date | Shared Roots with |
| | | | latest Android |
+=================+============+==============+===================+
| 4 | Ice Cream | 2011 | 37 |
| | Sandwich | | |
+-----------------+------------+--------------+-------------------+
| 5 | Lollipop | 2014 | 60 |
+-----------------+------------+--------------+-------------------+
| 7 | Nougat | 2016 | 74 |
+-----------------+------------+--------------+-------------------+
| 11 | Red Velvet | 2020 | 100 |
| | Cake | | |
+-----------------+------------+--------------+-------------------+
Table 1
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.
Jackson Expires 24 June 2025 [Page 7]
Internet-Draft Trust is non-negotiable December 2024
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 {[ChickenGameTheory]} 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
[SymantecDistrust].
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
[DistrustAfter], which bypasses the game of chicken with website
operators. This process has recently been enhanced with SCT-
Distrust-After, as pioneered by Google Chrome [EntrustSCTDistrust],
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 [CAMarketShare]. This transition has been smooth and
unremarkable for both website operators and users.
3.1.3. Key Rotation
The final root program operation that the TAI draft claims to improve
is a key rotation process for root certificates:
Jackson Expires 24 June 2025 [Page 8]
Internet-Draft Trust is non-negotiable December 2024
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
Section 3.1.1. 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
[CCADB] 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.
3.2. Trust Negotiation for Post-Quantum Certificates
[TAI] puts forward several ways in which trust negotiation could
benefit the transition to post-quantum.
3.2.1. 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.
Jackson Expires 24 June 2025 [Page 9]
Internet-Draft Trust is non-negotiable December 2024
This claim is also false. Cross-signing (described in Section 3.1.1)
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
[PQCrossSign]
3.2.2. Intermediate Suppression
Section 7.5 of [TAI] 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 [TAI] is evaluated for deployability in Section 4
and then compared to the existing alternatives in Section 5.1.
3.2.3. Future PQ Experiments
Merkle Tree Certificates [MTC] is a draft proposing a new post-
quantum authentication method for TLS which shsares a number of
authors with [TAI]. 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
Jackson Expires 24 June 2025 [Page 10]
Internet-Draft Trust is non-negotiable December 2024
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 [NistPQUpdate] (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.
3.3. Trust Negotiation and Root Program Divergence
The final set of use cases for trust negotiation proposed in [TAI]
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 [TLSInterim] 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)
3.3.1. Can divergence improve security?
The [TAI] 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)
Jackson Expires 24 June 2025 [Page 11]
Internet-Draft Trust is non-negotiable December 2024
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 [DelegatedCredentials] 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
[CABForumPrimer], 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 [EnterpriseACME] is what currently
prevents root programs enforcing shorter certificate lifetimes.
3.3.2. 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.
Jackson Expires 24 June 2025 [Page 12]
Internet-Draft Trust is non-negotiable December 2024
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.
3.3.3. 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.
Jackson Expires 24 June 2025 [Page 13]
Internet-Draft Trust is non-negotiable December 2024
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.
3.3.4. 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 [TAI]:
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. [NewRootsMotivation]
As discussed in Section 3.3.1, 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.
3.3.4.1. 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
Jackson Expires 24 June 2025 [Page 14]
Internet-Draft Trust is non-negotiable December 2024
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.
3.3.4.2. 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 [RussiaCA], [KazakhstanCA] and [MauritiusCA]. 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 [eIDAS]. 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.
Jackson Expires 24 June 2025 [Page 15]
Internet-Draft Trust is non-negotiable December 2024
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 [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
Jackson Expires 24 June 2025 [Page 16]
Internet-Draft Trust is non-negotiable December 2024
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 [eIDAS] can lead to
substantial differences in outcomes [eIDASOutcome].
3.3.4.3. 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.
Jackson Expires 24 June 2025 [Page 17]
Internet-Draft Trust is non-negotiable December 2024
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.
4. 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 [TAI]. 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.
4.1. 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
Jackson Expires 24 June 2025 [Page 18]
Internet-Draft Trust is non-negotiable December 2024
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.
4.2. 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
Jackson Expires 24 June 2025 [Page 19]
Internet-Draft Trust is non-negotiable December 2024
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.
4.3. 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 [LetsEncryptGuidance][CertbotGuidance].
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.
Jackson Expires 24 June 2025 [Page 20]
Internet-Draft Trust is non-negotiable December 2024
As a practical example, consider the fate of OCSP-Must Staple
[OCSPMustStaple], 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 [OCSPStapleFail].
4.4. 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.
Jackson Expires 24 June 2025 [Page 21]
Internet-Draft Trust is non-negotiable December 2024
4.5. Interaction with Encrypted Client Hello
TAI and ECH [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.
4.6. 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
Section 3).
For example, consider the proposed use case of easier CA removals for
root program operators which was evaluated in Section 3.1.2.
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.
Jackson Expires 24 June 2025 [Page 22]
Internet-Draft Trust is non-negotiable December 2024
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.
5. The Path Forwards
Section 3 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.
Jackson Expires 24 June 2025 [Page 23]
Internet-Draft Trust is non-negotiable December 2024
{#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.
Jackson Expires 24 June 2025 [Page 24]
Internet-Draft Trust is non-negotiable December 2024
5.1. 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 [IntermediatePreloading]. 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 [LECrossSign].
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.
5.1.1. Abridged Certificate Compression
Abridged Certificates [AbridgedCerts] is a draft already adopted by
the TLS Working Group. It is a type of TLS Certificate Compression
[CertCompression], 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.
Jackson Expires 24 June 2025 [Page 25]
Internet-Draft Trust is non-negotiable December 2024
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.
5.1.2. AIA Chasing with Storage
RFC 5280 describes the Authority Information Access Extension [AIA]
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
[AIAOverview]), OS Implementations (Windows s_channel, MacOS Secure
Transport [AIAOverview]) and middleboxes ([CiscoAIA], [BroadcomAIA])
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 [AIAExample].
Jackson Expires 24 June 2025 [Page 26]
Internet-Draft Trust is non-negotiable December 2024
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 [ICA]). 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 [AIAChrome], 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."
5.1.3. 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.
Jackson Expires 24 June 2025 [Page 27]
Internet-Draft Trust is non-negotiable December 2024
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.
5.2. 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.
5.2.1. 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
[EUCyberResiliencyAct] [UKSecureByDesign].
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
[Android7RootStore]. 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
[Android14RootStore]. 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
[CloudflareCertificateChanges] [LetsEncryptCertificateChanges]. As
Android 14 propagates through the ecosystem, currently at around 30%
of devices, we can largely put this challenge behind us.
Jackson Expires 24 June 2025 [Page 28]
Internet-Draft Trust is non-negotiable December 2024
5.2.2. 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
[CloudflareTLSFingerprint] [CurlTLSFingerprint]. 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.
5.2.3. 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.
Jackson Expires 24 June 2025 [Page 29]
Internet-Draft Trust is non-negotiable December 2024
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 [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.
6. Security Considerations
This document is almost entirely security considerations.
7. IANA Considerations
This document has no IANA actions.
8. Informative References
[AbridgedCerts]
Jackson, D., "Abridged Compression for WebPKI
Certificates", Work in Progress, Internet-Draft, draft-
Jackson Expires 24 June 2025 [Page 30]
Internet-Draft Trust is non-negotiable December 2024
ietf-tls-cert-abridge-02, 16 September 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
cert-abridge-02>.
[AIA] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
[AIAChrome]
Stark, E. and R. Sleevi, "AIA Fetching in Chrome for
Android", 23 September 2016,
<https://groups.google.com/a/chromium.org/g/net-dev/c/H-
ysp5UM_rk/m/TcKRw3pbDAAJ>.
[AIAExample]
BadSSL, "Example site with missing intermediates", 20
December 2024, <https://incomplete-chain.badssl.com/>.
[AIAOverview]
King, A., "AIA chasing for missing intermediate
certificates", 17 May 2017,
<https://github.com/python/cpython/
issues/62817#issuecomment-1093623029>.
[Android14RootStore]
Google, "Changes in Android 14", 4 October 2023,
<https://source.android.com/docs/core/ota/modular-system/
conscrypt>.
[Android7RootStore]
Google, "Changes to Trusted Certificate Authorities in
Android Nougat", 7 July 2016, <https://android-
developers.googleblog.com/2016/07/changes-to-trusted-
certificate.html>.
[AndroidRoots]
Google, "Android Root Store", 20 December 2024,
<https://android.googlesource.com/platform/system/ca-
certificates/+log/refs/heads/main/files>.
[BroadcomAIA]
Broadcom, "Support for AIA Fetching technology", 20
December 2024,
<https://knowledge.broadcom.com/external/article/235295/
support-for-aia-fetching-technology.html>.
Jackson Expires 24 June 2025 [Page 31]
Internet-Draft Trust is non-negotiable December 2024
[CABForumPrimer]
Digicert, "Introduction to the CA/B Forum", 21 January
2021, <https://www.digicert.com/blog/digicerts-
introduction-to-the-cab-forum>.
[CAMarketShare]
Hurst, R., "WebPKI Marketshare Update", 26 December 2022,
<https://x.com/rmhrisk/status/1739775001920950730>.
[CCADB] "The Common CA Database", 20 December 2024,
<https://www.ccadb.org/>.
[CertbotGuidance]
Certbot, "Certbot DNS Challenge Guidance", 20 December
2024, <https://certbot-dns-ovh.readthedocs.io/en/stable/>.
[CertCompression]
Ghedini, A. and V. Vasiliev, "TLS Certificate
Compression", RFC 8879, DOI 10.17487/RFC8879, December
2020, <https://www.rfc-editor.org/rfc/rfc8879>.
[ChickenGameTheory]
Wikipedia, "Chicken (Game Theory)", 20 December 2024,
<https://en.wikipedia.org/wiki/Chicken_(game)>.
[CiscoAIA] Cisco, "Secure Web Appliance Best Practices", 20 December
2024,
<https://www.cisco.com/c/en/us/support/docs/security/
secure-web-appliance/220375-use-secure-web-appliance-best-
practices.html>.
[CloudflareCertificateChanges]
Cloudflare, "How we ensure Cloudflare customers aren't
affected by Let's Encrypt's certificate chain change", 12
April 2024, <https://blog.cloudflare.com/shortening-lets-
encrypt-change-of-trust-no-impact-to-cloudflare-
customers/>.
[CloudflareTLSFingerprint]
Cloudflare, "JA3/JA4 Fingerprint", 20 December 2024,
<https://developers.cloudflare.com/bots/concepts/
ja3-ja4-fingerprint/>.
[CrossSignStudy]
Hiller, J., Amann, J., and O. Hohlfeld, "The Boon and Bane
of Cross-Signing Shedding Light on a Common Practice in
Public Key Infrastructures", 9 November 2020,
<https://arxiv.org/pdf/2009.08772>.
Jackson Expires 24 June 2025 [Page 32]
Internet-Draft Trust is non-negotiable December 2024
[CurlTLSFingerprint]
Stenberg, D., "Curl’s TLS fingerprint", 2 September 2022,
<https://daniel.haxx.se/blog/2022/09/02/curls-tls-
fingerprint/>.
[DelegatedCredentials]
Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla,
"Delegated Credentials for TLS and DTLS", RFC 9345,
DOI 10.17487/RFC9345, July 2023,
<https://www.rfc-editor.org/rfc/rfc9345>.
[DistrustAfter]
Mozilla, "Additional CA Trust Changes - Distrust After",
31 July 2023, <https://wiki.mozilla.org/CA/
Additional_Trust_Changes#Distrust_After>.
[ECH] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
Encrypted Client Hello", Work in Progress, Internet-Draft,
draft-ietf-tls-esni-22, 15 September 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
esni-22>.
[eIDAS] Mozilla, "Secret EU law threatens Internet security", 2
November 2023, <https://last-chance-for-eidas.org>.
[eIDASOutcome]
Mozilla, "European Parliament votes on eIDAS, averting
threat to web security", 29 February 2024,
<https://securityriskahead.eu/wp-content/uploads/2024/02/
Mozilla_-press-release_eIDAS-EP-Plenary-adoption.pdf>.
[EnterpriseACME]
smallstep, "The Embarrassing State of Enterprise ACME
Support", 20 May 2024, <https://smallstep.com/blog/the-
embarrassing-state-of-enterprise-acme/>.
[EntrustSCTDistrust]
Censys, "Removing Entrust from Chrome's Root Store", 11
July 2024, <https://censys.com/google-entrust-internet/>.
[EUCyberResiliencyAct]
RPC, "The EU's Cyber Resilience Act", 10 December 2024,
<https://www.rpclegal.com/thinking/data-and-privacy/the-
eu-cyber-resilience-act/>.
Jackson Expires 24 June 2025 [Page 33]
Internet-Draft Trust is non-negotiable December 2024
[FastlyCRT]
Sectigo, "Certificate Trust Graph for Certainly", 20
December 2024,
<https://crt.sh/?graph=15746089670&opt=nometadata>.
[GTSCrossSign]
Hurst, R., "Google, HTTPS, and device compatibility", 15
March 2021, <https://security.googleblog.com/2021/03/
google-https-and-device-compatibility.html>.
[ICA] Thomson, M., Kampanakis, P., Bytheway, C., and B.
Westerbaan, "Suppressing CA Certificates in TLS 1.3", Work
in Progress, Internet-Draft, draft-kampanakis-tls-scas-
latest-02, 8 July 2022,
<https://datatracker.ietf.org/doc/html/draft-kampanakis-
tls-scas-latest-02>.
[IntermediatePreloading]
Mozilla, "Preloading Intermediate CA Certificates into
Firefox", 13 November 2020,
<https://blog.mozilla.org/security/2020/11/13/preloading-
intermediate-ca-certificates-into-firefox/>.
[KazakhstanCA]
OONI, "Kazakhstan TLS MITM attacks and blocking of news
media, human rights, and circumvention tool sites", 19
September 2024,
<https://ooni.org/post/2024-kazakhstan-report/>.
[LECrossSign]
Helme, S., "Cross-Signing and Alternate Trust Paths; How
They Work", 22 June 2020, <https://scotthelme.co.uk/cross-
signing-alternate-trust-paths-how-they-work/>.
[LetsEncryptCertificateChanges]
Let's Encrypt, "Shortening the Let's Encrypt Chain of
Trust", 10 July 2023, <https://letsencrypt.org/2023/07/10/
cross-sign-expiration/>.
[LetsEncryptGuidance]
Let's Encrypt, "Let's Encrypt Challenge Types Guidance",
20 December 2024,
<https://letsencrypt.org/docs/challenge-types/>.
Jackson Expires 24 June 2025 [Page 34]
Internet-Draft Trust is non-negotiable December 2024
[MauritiusCA]
Internet Society, "Mauritius Must Not Fall into the ‘Mass
Surveillance’ Trap", 28 May 2021,
<https://www.internetsociety.org/blog/2021/05/mauritius-
must-not-fall-into-the-mass-surveillance-trap/>.
[MTC] Benjamin, D., O'Brien, D., and B. Westerbaan, "Merkle Tree
Certificates for TLS", Work in Progress, Internet-Draft,
draft-davidben-tls-merkle-tree-certs-03, 5 September 2024,
<https://datatracker.ietf.org/doc/html/draft-davidben-tls-
merkle-tree-certs-03>.
[NewRootsMotivation]
Beck, B., "Mail on New Roots", 14 June 2024,
<https://mailarchive.ietf.org/arch/msg/tls/kBUBdLGEo-
b5ywGoYFoJhoyW7KY/>.
[NistPQUpdate]
NIST, "NIST Releases First 3 Finalized Post-Quantum
Encryption Standards", 13 August 2024,
<https://www.nist.gov/news-events/news/2024/08/nist-
releases-first-3-finalized-post-quantum-encryption-
standards>.
[OCSPMustStaple]
Sullivan, N., "High-reliability OCSP stapling and why it
matters", 10 July 2017, <https://blog.cloudflare.com/high-
reliability-ocsp-stapling/>.
[OCSPStapleFail]
Böck, H., "The Problem with OCSP Stapling and Must Staple
and why Certificate Revocation is still broken", 19 May
2017, <https://blog.hboeck.de/archives/886-The-Problem-
with-OCSP-Stapling-and-Must-Staple-and-why-Certificate-
Revocation-is-still-broken.html>.
[PQCrossSign]
IETF, "Transitioning to PQC Certificates", 27 May 2024,
<https://mailarchive.ietf.org/arch/msg/tls/
b_S23Rk0yvleoT3D0BGUTYFut80/>.
[RussiaCA] EFF, "You Should Not Trust Russia’s New “Trusted Root
CA”", 15 March 2022,
<https://www.eff.org/deeplinks/2022/03/you-should-not-
trust-russias-new-trusted-root-ca>.
Jackson Expires 24 June 2025 [Page 35]
Internet-Draft Trust is non-negotiable December 2024
[SleeviCrossSign]
Sleevi, R., "Discussion on cross-signing and key
rollover.", 2 August 2019,
<https://groups.google.com/g/mozilla.dev.security.policy/
c/-4B6g8T-kis/m/CKMS2LR7EgAJ>.
[Splinternet]
Internet Society, "MWhat Is a Splinternet? And Why You
Should Be Paying Attention", 23 March 2022,
<https://www.internetsociety.org/blog/2022/03/what-is-the-
splinternet-and-why-you-should-be-paying-attention/>.
[SymantecDistrust]
Mozilla, "Symantec Issues and Timeline", 10 October 2018,
<https://wiki.mozilla.org/CA/Symantec_Issues>.
[TAI] Beck, B., Benjamin, D., O'Brien, D., and K. Nekritz, "TLS
Trust Anchor Identifiers", Work in Progress, Internet-
Draft, draft-beck-tls-trust-anchor-ids-03, 18 December
2024, <https://datatracker.ietf.org/doc/html/draft-beck-
tls-trust-anchor-ids-03>.
[TLSInterim]
"TLS Interim Materials", 1 October 2024,
<https://datatracker.ietf.org/meeting/interim-2024-tls-
01/session/tls>.
[UKSecureByDesign]
Department for Science and Technology, UK Gov, "Secure by
design", 5 December 2024,
<https://www.gov.uk/government/collections/secure-by-
design#consumer-connectable-product-security-guidance>.
Acknowledgments
TODO acknowledge.
Author's Address
Dennis Jackson
Mozilla
Email: ietf@dennis-jackson.uk
Jackson Expires 24 June 2025 [Page 36]