(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
