[TLS]Re: WG Adoption for TLS Trust Expressions

[David Benjamin]

Resending this since it seems IETF lists were broken recently (
https://www.ietf.org/blog/ietf-mailing-list-delivery-issues/). Hopefully it
works this time.

On Thu, May 9, 2024 at 10:45 AM David Benjamin 
wrote:

> Hi Richard. Thanks for the comments! Replies inline.
>
> On Mon, May 6, 2024 at 10:23 AM Richard Barnes  wrote:
>
>> Hi all,
>>
>> Coming in late here.  Appreciate the discussion so far.  FWIW, here's how
>> I'm thinking through this:
>>
>> I would frame the basic problem here as follows, since I think the use
>> cases presented are all basically corollaries: Root store fragmentation
>> makes it hard for server operators to make sure they can authenticate to
>> all of the clients they want to connect with.  Note that the pain is
>> non-zero regardless of technology.  The more clients have differing
>> requirements, the more work servers are going to have to do to support them
>> all.
>>
>> Pain = (Amount of fragmentation) * (Pain per fragmentation)
>>
>> The question at issue here is how trust expressions affect the inputs to
>> this equation.
>>
>> Shifting from a single-certificate to a multi-certificate world shifts
>> the pain, from "How do I pick the most widely accepted cert?" to "How do I
>> make sure I have the right selection of certificates?"  I probably agree
>> that this is a net reduction in pain for a given level of fragementation.
>>
>
> I think we’re broadly in agreement here. Fragmentation exists today, both
> between different root programs and between versions of a given client and
> there is a significant amount of pain involved for affected server
> operators with no option but to find a new ubiquitously-trusted CA and
> reissue.
>
> 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.
>
> It’s worth noting that, for a given set of target clients, picking the
> most widely accepted certificate is not merely painful but potentially
> infeasible. Picking a larger selection of certificates allows the server
> operator to meet their needs. There is still some cost to selecting from
> too many certificates, but trust expressions greatly relieves the pressures
> that, again, ultimately are paid by user security.
>
> We also anticipate many of those costs can be mitigated by instead
> imposing smaller costs on CAs, who already have existing relationships with
> root programs. Indeed, CAs already make decisions about supported clients,
> by deciding which cross-signs and intermediates to include and which to
> retire. Trust expressions makes these decisions more explicit.
>
>
>> I probably also agree with Dennis, though, that reducing the pain at a
>> given level of fragmentation will increase the temptation to more
>> fragmentation.  The country-level stuff is there, but even some of the
>> putative use cases look like more fragmentation -- more algorithms,
>> changing root store policies more frequently.  Playing the combinatorics
>> out here, how many certs is a server going to have to maintain?
>>
>
> To some degree, yes, we want to increase fragmentation *when it is
> necessary to benefit user security*. Fragmentation is an inherent
> consequence of root program changes, and root programs often need changes
> to meet user security (and, with post-quantum, performance) needs, but the
> costs today are prohibitive to the point that root programs cannot
> effectively meet those needs.
>
> Of course, unnecessary fragmentation is undesirable. Trust expressions
> fixes the prohibitive costs but, as you allude to, there are still costs.
> We don’t want servers to need to maintain unboundedly many certificates.
> However, note that these same costs are pressure against excessive,
> unnecessary fragmentation.
>
> It’s hard to say exact numbers at this stage. We can only learn with
> deployment experience, hence our desire to progress toward adoption and
> experimentation.
>
>
>> As an aside here, speaking as someone who used to run a root program, I'm
>> not sure that reducing the barriers to adding new CAs to a root program is
>> a net benefit.  Obviously we don't want things to ossify, but it seems like
>> experience has shown that small, niche CAs cause more trouble in terms of
>> compliance checking and misissuance than the benefit that they bring in
>> terms of diversity.
>>
>
> This is an important point; most modern root programs including Chrome
> 
> and Mozilla  are trending
> towards increased requirements on CAs to become trusted, including greater
> agility among trust anchors. This agility reduces the 

[TLS]Re: WG Adoption for TLS Trust Expressions

[David Benjamin]

Resending this since it seems IETF lists were broken recently (
https://www.ietf.org/blog/ietf-mailing-list-delivery-issues/). Hopefully it
works this time.

On Thu, May 9, 2024 at 10:40 AM David Benjamin 
wrote:

> (replies inline)
>
> On Sun, May 5, 2024 at 6:48 PM Dennis Jackson  40dennis-jackson...@dmarc.ietf.org> wrote:
>
>> Hi David, Devon, Bob,
>>
>> I feel much of your response talks past the issue that was raised at
>> IETF 118.
>>
>> The question we're evaluating is NOT "If we were in a very unhappy world
>> where governments controlled root certificates on client devices and used
>> them for mass surveillance, does Trust Expressions make things worse?".
>> Although Watson observed that the answer to this is at least 'somewhat',
>> I agree such a world is already maxed at 10/10 on the bad worlds to live
>> in scale and so it's not by itself a major problem in my view.
>>
>> The actual concern is: to what extent do Trust Expressions increase the
>> probability that we end up in this unhappy world of government CAs used for
>> mass surveillance?
>>
>> The case made earlier in the thread is that it increases the probability
>> substantially because it provides an effective on-ramp for new CAs even
>> if they exist entirely outside of existing root stores. Websites can
>> adopt such a CA without being completely broken and unavailable as they
>> would be today. Although I think it's unlikely anyone would
>> independently do this, it's easy to see a website choosing to add such a
>> certificate (which is harmless by itself) if a government incentivized or
>> required it.  Trust Expressions also enables existing CAs to force-push a
>> cert chain from a new CA to a website,  without the consent or awareness
>> of the website operator, further enabling the proliferation of untrusted
>> (and presumably unwanted) CAs.
>>
>> These features neatly solve the key challenges of deploying a government
>> CA, which as discussed at length in the thread, are to achieve enough
>> legitimacy through website adoption to have a plausible case for enforcing
>> client adoption. The real problem here is that you've (accidentally?)
>> built a system that makes it much easier to adopt and deploy any new CA
>> regardless of trust, rather than a system that makes it easier to deploy
>> & adopt any new *trusted* CA. If you disagree with this assessment, it
>> would be great to hear your thoughts on why. Unfortunately, none of the
>> arguments in your email come close to addressing this point and the text
>> in the draft pretty much tries to lampshade these problems as a feature.
>>
> 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.
>
>
>> The other side of this risk evaluation is assessing how effectively Trust
>> Expressions solves real problems.
>>
>> Despite a lot of discussion, I've only seen one compelling unsolved
>> problem which Trust Expressions is claimed to be able to solve. That is
>> the difficulty large sites have supporting very old clients with
>> out-of-date root stores (as described by Kyle). This leads to sites
>> using complex & brittle TLS fingerprinting to decide which certificate
>> chain to send or to sites using very particular CAs designed to maximize
>> compatibility (e.g. Cloudflare's recent change).
>>
>> However, it's unclear how Trust Expressions solves either fingerprinting
>> or the new trusted root ubiquity challenge. To solve the former, we're
>> relying on the adoption of Trust Expressions by device manufacturers who
>> historically have not been keen to adopt new TLS extensions. For the
>> latter, Trust Expressions doesn't seem to solve anything. Sites / CDNs are
>> still forced to either have a business arrangement with a single
>> suitably ubiquitous root or to conclude multiple such arrangements (which
>> come with considerable baggage) with both new and ubiquitous roots - in
>> return for no concrete benefit. If we 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.
>
>
>> I won't detail them here, but it seems like there are simpler and more
>> effective alternatives that would address the underlying problem, e.g.
>> through root stores encouraging