On Fri, May 24, 2024 at 3:46 PM Watson Ladd <watsonbl...@gmail.com> wrote:
> To be clear, in Denis's scenario Ebonia requires all servers to obtain > a cert from Honest Ahmed's > (https://bugzilla.mozilla.org/show_bug.cgi?id=647959) Ebonian Secure > CA. Server operators who complain that this will break clients are > told that it will have a trust expression that currently isn't used, > but government inspectors will use it to see if the cert is installed. > Then in step 2 they use the number of certs issued to bolster the > argument for inclusion. I don't see how Trust Expressions isn't making > this scenario easier. > > Furthermore the decision to add a CA is multifacited and balances the > utility to subscribers against the security costs. I am on the record > as an advocate for aggressively swinging towards quantifying the > utility here: no one is entitled to get trusted just because they can > comply with the CA/B forum rules. The number of certs issued (and > hence servers covered) is part of the utility calculation. > Step 2 in this scenario is not actually a compelling argument for the root program, precisely because of certification negotiation. To expand on this a bit: Adding a CA means trusting their (unpredictable) future actions. So, yes, each trusted CA carries some risk. The role of a root program is to make subjective judgments about this risk. And, yes, that means folks discuss things like "utility" to try to capture benefit vs risk tradeoffs of adding a CA. Users directly see compatibility issues, so it’s natural that folks talk about compatibility when thinking about this. It's then natural to think about these compatibility judgements being gamed or misrepresented, but this game-ability is why compatibility judgements are inherently problematic. They dilute the security-critical judgment (trustworthiness) with an unrelated one (popularity among sites, whose first-order incentives are availability, not CA trustworthiness). And yet these pressures are real *today*. Root programs are pressured *today* to trust widely-used CAs so that sites using them can work. Sure, the site could use a different CA, but every site operator will tell you CA changes are extremely difficult and risky. Convincing them to move is a difficult proposition. In contrast, the root program trusting a CA has zero compatibility risk, only security risk. It takes an egregious indication of untrustworthiness to offset those pressures, so the default is that users end up taking on security risk. Trust expressions fix the root problem here. There is a zero-compatibility-risk action available to the site operator: keep serving the old cert while adding a new one. Use by many servers, in a multi-certificate world, is no longer as compelling an argument to trust a root. By releasing this pressure valve, we give root programs more room to manage user security risk. This is even clearer in the above Ebonia scenario, the reason the server operators were willing to add that root by trust expressions was *because they could keep their existing certificate working*. Those servers then contribute *zero* compatibility pressure on the root program because their existing certificates work. A server would have to *only* serve the Ebonia root to contribute pressure. That's something they can already do today without trust expressions. (And are strongly incentivized against doing so for all usual compatibility reasons.) There isn't a step 2 here. We recently pushed a draft-03 with some text to capture this. The first addition discusses the above: https://www.ietf.org/archive/id/draft-davidben-tls-trust-expr-03.html#section-11.1-3 The second discusses the implications of serving a cert more generally, and is intended as a reference both for this discussion, and whenever anyone tries to convince a root program to trust an untrustworthy CA by virtue of an unrelated popularity contest. https://www.ietf.org/archive/id/draft-davidben-tls-trust-expr-03.html#name-serving-multiple-certificat David
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
