On Tue, May 21, 2024 at 4:56 PM David Benjamin <david...@chromium.org> wrote: > > Hi Richard. Thanks for the comments! Replies inline. > > On Mon, May 6, 2024 at 10:23 AM Richard Barnes <r...@ipv.sx> 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'm sort of confused here. As I understood it Trust Expressions communicates from the client to the server what CAs the client would accept, and lets the server that would have two separate certs from different roots serve the union of the clients that accept each one easily. I'm not sure how that imposes costs on CAs. Furthermore I'm not entirely sure how much it helps in the case of distrust. The server still needs to acquire new certificates unless the ones it has cover the set of clients even post the distrust. What really reduces the cost here is automation in changing to a more commonly supported root easily. Even after Trust Expressions that automation is required now to maintain a covering set, while before it's a covering set of size one. The decisions Trust Expressions communicate aren't CA decisions either. The cross-signed intermediate on the server is sent back in the chain and extends the reach of the root that the client trusts. I'm just confused. I think there's a way where the problem we're trying to solve has been defined narrowly enough to make Trust Expressions the right solution, but the problems that server operators and users care about are a bit higher level. > >> >> 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 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. > > We do not expect that to change. Trust expressions do not remove any barriers from including a CA in a root program. Rather, it removes the ubiquity barrier preventing server operators from serving certificates from that CA, to clients that have already chosen to trust it. > >> >> 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. > > > 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, but it would need to be more concrete to be a sketch of a solution. Was this the option you had in mind? > - Root-program-specific roots seem to require exactly a primitive like trust expressions. > - A global timestamp is not viable because root programs make different decisions at different times, for a variety of reasons. > > Perhaps you could elaborate on what you had in mind? > > But, as we said, we’re much more interested in the deployment model than the exact mechanism and think these details would be excellent working group discussion topics over the course of working on this document. (And we’ll certainly keep the “Considered Alternatives” section of the explainer updated.) > >> >> 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 > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org -- Astra mortemque praestare gradatim
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
