[TLS]Re: WG Adoption for TLS Trust Expressions

[Dennis Jackson <[e-mail]>]

Hi David, Devon, Bob,

Response to both your recent mails below:

On Thu, May 9, 2024 at 10:45 AM David Benjamin <[e-mail]> 
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 <[e-mail]> 
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