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 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? 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. Given all that, I find myself pretty firmly on the fence here. On the one hand, I would find more appeal in a more limited solutions (such as those Dennis raises) that addressed some of the fragmentation problems without full generality. On the other hand, if there were a clear argument that fragmentation could be contained, that could make the current proposal more plausible. Hope that helps, --Richard On Sun, May 5, 2024 at 9: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. > > 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? > > 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)? > > 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 > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
