Hi David, Devon, Bob,
Response to both your recent mails below:
On Thu, May 9, 2024 at 10:45 AM David Benjamin <david...@chromium.org>
wrote:
We’re particularly concerned about this server operator pain because
it translates to security risks for billions of users. If root program
actions cause server operator pain, there is significant pressure
against those actions. The end result of this is that root store
changes happen infrequently, with the ultimate cost being that user
security cannot benefit from PKI improvements.
The claim here is that Trust Expressions is going to make it easier to
remove CAs by reducing the pain to server operators of CA distrust? This
seems to be incompatible with the draft's intent for CAs to provision
the server's certificate chains without interaction with the website
operator. Why is the CA you're distrusting ever going to voluntarily
enable their own removal by transitioning their subscribers to a
different CAs cert chain?
It’s hard to say exact numbers [of trust store labels / versions] at
this stage. We can only learn with deployment experience, hence our
desire to progress toward adoption and experimentation.
Leaving aside the concerns about what other parties may abuse this for,
can you talk concretely about how *you* would use it? Would Chrome and
Android Webview share the same trust expressions label? Would desktop
Chrome and mobile Chrome? Would Chrome Canary and Chrome Release? Would
Chrome and Chromium? Would you expose the Trust Expressions API to
Android applications? I don't think the answer matters for the concerns
that I'm articulating around both risks and effectiveness, but I have a
slightly morbid**curiosity about how far through you've thought this
proposal.
This is an important point; most modern root programs including Chrome
<https://www.chromium.org/Home/chromium-security/root-ca-policy/moving-forward-together/>
and Mozilla <https://wiki.mozilla.org/CA/Root_CA_Lifecycles> are
trending towards increased requirements on CAs to become trusted,
including greater agility among trust anchors. This agility reduces
the risk of powerful, long-lived keys and allows for faster adoption
of security improvements, but poses additional pain on subscribers who
can only deploy one certificate to meet the needs of a set of clients
that are changing faster than ever before.
Are those requirements truly changing faster than ever before? The vast
majority of the pain in this space has been caused by the fact that the
Android Root Store could only be updated by an OTA update from the OEM
and so was effectively abandonware. I understand that Google finally
fixed this in Android 14, released October 2023. Meanwhile, downloading
Firefox yields a modern root store for any Android device released in
the past 10 years (Android 5 - Lollipop, 2014).
Momentum very much seems to be pointing in the opposite direction to
what you claim, as the old abandoned devices age out, they're being
replaced by devices that are much easier to keep up to date. Similarly,
various countries now have laws on the books requiring a minimum number
of years of security updates for devices and manufacturer's are
responding by vastly improving their supported lifetimes. This situation
improves even further with the coming shift to PQ (described below).
There are indeed costs to fragmentation, but those costs themselves
provide the pressure against unnecessary fragmentation. We’re not
aware of any more limited solution that would still meet the
requirements here. Did you mean the ones in
https://mailarchive.ietf.org/arch/msg/tls/XXPVFcK6hq3YsdZ5D-PW9g-l8fY/
Looking at these:
- Cross-signing is a broad space. We discuss it briefly in the
explainer
<https://github.com/davidben/tls-trust-expressions/blob/main/explainer.md#path-building>,
but it would need to be more concrete to be a sketch of a solution.
Was this the option you had in mind?
Cross-signing is well understood.
The easiest case is when an already trusted CA wishes to transition to
new key material. The CA can cross sign both the new root and the new
intermediates as Let's Encrypt has for ISRG X1 and ISRG X2 [1]. The main
drawback is increased certificate chain size. Adopted drafts like
Abridged Certs [2] completely eliminate it.
The alternative use case is when a new CA wants to launch. Currently,
it's left to the CA to negotiate with incumbents to obtain a cross
signed certificate and many do, e.g. Let's Encrypt from IdenTrust [3],
SSL.com from Certum [4]. If you feel that it should be made even easier,
an argument I'm sympathetic to, that's an easy policy decision for Root
Programs to make.
On Thu, May 9, 2024 at 10:40 AM David Benjamin <david...@chromium.org>
wrote:
Our understanding of your argument is that it will be easier for
governments to force clients to trust a CA if a sufficient number of
websites have deployed certificates from that CA. We just don’t
agree with this assertion and don’t see websites’ deployment as a
factor in trust store inclusion decisions in this scenario.
I asked why you believed that. Flat denial of the direct connection
between making it easier to deploy a new CA (regardless of any root
store inclusion) and the ease of deploying a new CA for bad purposes is
a weird hill to die on.
Ifwe had Trust Expressions deployed today, how would life be
better for LE / Cloudflare or other impacted parties?
It isn’t necessary for older device manufacturers to adopt Trust
Expressions. Rather, Trust Expressions would be adopted by modern
clients, allowing them to improve user security without being held
back by older clients that don’t update. Servers may still need to
navigate intersections and fingerprinting for older clients, but
this will be unconstrained by modern ones. It will also become
simpler, with fingerprinting less prevalent, as older clients fall
out of the ecosystem.
You seem to be agreeing that it wouldn't solve any of the issues which
people have come to the list to talk about. Rather, you're now anchoring
your claims around improving security. But its totally unclear what
security benefits you're actually delivering.
To pick an example you've repeatedly highlighted, can you
clarify how Trust Expressions will speed the transition to a PQ
PKI? Specifically, how much earlier do you expect a given site
to be able to deploy a PQ cert chain in the case of TE adoption
vs without TE adoption (and why)?
The transition benefits are briefly summarized in Section 9.2. We
anticipate a PQ transition will result in many PQ roots coming
online in a short time. It is implausible that every root program
will qualify them at the same time and in the same order.
That means, during the transition, different trust stores will have
different subsets of the final “common” PQ root set. (But, again, as
root programs do not and cannot actually coordinate, it is not a
truly common set.) Negotiation allows early adopters to start using
PQ CAs where they can, while still remaining compatible with the
root programs that support PQ but not yet with their chosen CAs.
Without this, everyone must delay until things settle.
The approach you outline is to basically make easier for slower moving
CAs to transition to PQ. Is this desirable? Aren't users better off in a
world where CAs are racing to be the first to deploy PQ and enjoy
widespread trust from root programs? Without there being any direct
benefit to being early in the PQ transition, we're likely to see CAs
reluctant to make the considerable investment in the necessary hardware,
software and procedures. After all, why not let someone else go first
and pave the way?
We'll also want to consider much shorter lifetimes for PQ root
certificates to ensure that there cannot be a repeat of the Android
debacle. I understand the Google Root Program has already announced an
intent to limit root certificates to 7 year lifetimes [5]. This would
effectively shift responsibility for handling old insecure devices from
website operators to device manufacturers, where it correctly belongs.
Compared to the alternatives, Trust Expressions seems to solve the
problems less effectively and introduce much greater risks. If you
really feel the opposite is true, I would strongly encourage you to:
a) Write up concrete security benefits which Trust Expressions uniquely
enables. It's important to explain not just how Trust Expressions solves
the problem, but also why incentives are aligned for the various
stakeholders to deploy it correctly such that those benefits can be
realized.
b) Make a good faith attempt to engage with the concerns raised about
the risks. Think through how a party with different goals to your own
could exploit the negotiation offered by Trust Expressions for their own
purposes. If your goal was instead to enable surveillance and domestic
control of the web for your government, how would widespread support for
Trust Expressions help you?
Best,
Dennis
[1] https://letsencrypt.org/images/isrg-hierarchy.png
[2] http://github.com/tlswg/draft-ietf-tls-cert-abridge/
[3] https://letsencrypt.org/2015/10/19/lets-encrypt-is-trusted
[4]
https://www.ssl.com/blogs/ssl-com-legacy-cross-signed-root-certificate-expiring-on-september-11-2023/
[5]
https://www.chromium.org/Home/chromium-security/root-ca-policy/moving-forward-together/#encouraging-modern-infrastructures-and-agility
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
