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 <david...@chromium.org> wrote: > (replies inline) > > On Sun, May 5, 2024 at 6:48 PM Dennis Jackson <ietf= > 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 cross-signing or offering cross-signing >> services themselves and using existing techniques to avoid any impact at >> the TLS layer. >> >> I'm struggling to see it being an even partially effective solution for any >> of the other proposed use cases. 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. > > (We’ve also detailed in past messages how trust expressions help with size > in the steady state, not just the transition.) > > >> David, Devon & Bob wrote: >> >> We acknowledge that achieving this level of agility requires a >> significant amount of design and implementation work for web servers, >> certificate automation clients/servers, and clients to support, but we >> believe >> the improvements called out in some of the discussions on this thread >> strongly outweigh these costs [...] >> >> [...] We think this will drastically improve the ability to migrate the >> Internet to PQC—not just in terms of a faster timeline, but because >> trust anchor agility will enable the community to develop fundamentally >> better solutions for authentication, through reduced experimentation >> costs >> >> I can completely understand why Trust Expressions seems to bring >> substantial benefits to *you* (as root store operators) but I'm much >> less clear on what the benefits are to anybody else on your list and what >> incentive they have to do all this work to deploy it. The only >> stakeholders that seem to benefit are CAs and I'm quite wary of the idea >> that we a) endow them with more centralized control, b) make CAs easier >> to create and proliferate, and c) encourage them to specialize in >> capturing specific narrow fiefdoms signalled by Trust Expressions - rather >> than competing with each other in a unitary-ish WebPKI. >> >> On the other hand, even if it were to prove useful and widely deployed, >> I (and others) see a substantial and serious risk that you seem >> reluctant to acknowledge or engage with. >> >> Best, >> >> Dennis >> >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
