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 <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 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 > <https://www.chromium.org/Home/chromium-security/root-ca-policy/moving-forward-together/> > and Mozilla <https://wiki.mozilla.org/CA/Root_CA_Lifecycles> 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 > <https://github.com/davidben/tls-trust-expressions/blob/main/explainer.md#path-building>, > 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
