On Fri, May 24, 2024 at 10:14 AM Dennis Jackson <ietf= 40dennis-jackson...@dmarc.ietf.org> wrote:
> Hi David, > > The certification chains issued to the server by the CA comes tagged with > a list of trust stores its included in. The named trust stores are > completely opaque to the server. These chains and names may not be trusted > by any client nor approved by any server, they are issued solely by the CA > as opaque labels. These chains sit on the server and will not be used > unless a client connects with the right trust store label but obviously can > easily be scanned for by anyone looking to check how pervasively deployed > the alternate trust store is. > > Do you dispute any part of that? Most of what you wrote went off on a > completely different tangent. > > Of course, whether this property (whether servers can usefully pre-deploy > not-yet-added trust anchors), which trust expressions does not have, even > matters boils to whether a root program would misinterpret availability in > servers as a sign of CA trustworthiness, when those two are clearly > unrelated to each other. > > Again, my primary concern here is not around the behavior of individual > root stores, this is not relevant to the concern I'm trying to communicate > to you. I know folks from all of the major root stores have great faith in > their judgement and technical acumen. > > My concern is that Trust Expressions upsets a fragile power balance which > exists outside of the individual root stores. There is an eternal war > between governments pushing to take control of root stores and the security > community pushing back. This battle happens in parliaments and governments, > between lawmakers and officials, not within root stores and their > individual judgement largely does not matter to this war. The major > advantages we as the security community have today are that: > > a) These attempts to take control for surveillance are nakedly obvious > to the local electorate because crappy domestic roots have no legitimate > purpose because they can never achieve any real adoption. > > b) If a root store were to bow to pressure and let in a root CA used > for interception, every other country has an interest in preventing that. > An international WebPKI means that we are either all secure, or all > insecure, together. > > Trust Expressions, though intended to solve completely different problems, > will accidentally eradicate both of these advantages. Firstly, it provides > a nice on ramp for a new domestic trust store, mostly through the > negotiation aspect but also through the CA pre-distribution. Secondly, by > enabling fragmentation along geographic boundaries whilst maintaining > availability of websites. Without Trust Expressions, we cannot balkanize > TLS. With Trust Expressions, we can and we know people who want to (not > anyone in this thread). > > If you still do not understand this wider context within which all of our > work sits, I do not think further discussion between you and I is going to > help matters. > > I would suggest we focus our discussion on the use cases of Trust > Expressions and how exactly it would work in practice - these concerns I > shared earlier in the thread are solely technical and operational and you > and I might be able to make better progress towards a common understanding. > > Best, > Dennis > Hi Dennis, I’m replying in this separate thread to respond to some of your comments and responses around the risks related to Trust Expressions so that we can keep the primary thread focused on the technical matters. First, let’s agree on the facts of what Trust Expressions does. Trust Expressions makes it easier to deploy new CAs. Specifically, it makes it easier for servers to use certificate chains issued by new CAs. Trust Expressions does not enable the use/adoption/deployment of new CAs regardless of trust. It only does so for trusted CAs, whereby trusted I mean the CA is in a client’s root store. David Benjamin explains [1] this in detail in his latest reply. If you permit me to summarize what’s already been said on the thread: At the time of certificate issuance, the CA provides the web server with metadata (in the form of a TrustStoreInclusionList, section 5.1 [2]) indicating which trust stores contain the root for that certificate chain. When responding to a ClientHello that contains the trust_expressions TLS extension, the server will only use Trust Expressions if it has a certificate chain that at issuance time matched one of the client’s TrustStores. Trust Expressions only enables the deployment of certs from a new CA if that CA is trusted by a client when the CA sends the subscriber the TrustStoreInclusionList alongside the certificate chain. The client has to trust the CA before Trust Expressions enables use of a new CA, hence it only enables new CAs that are trusted. If the CA makes up its own trust store label to use for deployment, clients would have to be compelled to advertise that trust store label for this “pre-distribution” of certificates to have any use. I assume that the only way that Trust Expressions enables government compulsion of CA adoption is if part of the compulsion involves browser vendors deciding to bifurcate their root store based on client geography or jurisdiction. If the browser vendor maintains a single root store and consistently advertises that in the trust_expressions extension worldwide, then Trust Expressions plays no role in the government compulsion of adopting a new CA. I say this because this means that for Trust Expressions to play a role in supporting government compulsion of adopting a new CA, at some point in the process the browser vendor made the decision to bifurcate their root store and support different sets of CAs in different regions. Let’s consider an example where country XX mandates trust in their government CA, and this causes a browser vendor Iceweasel to bifurcate their trust store. In the trust_expressions extension, this could look something like advertising (iceweasel, 127) everywhere, and in country XX advertising both (iceweasel, 127) and (iceweasel-xx, 127). Note that it doesn’t work for Iceweasel to advertise only (iceweasel-xx, 127) in country XX, because when connecting to international servers, they will only be configured to know what (iceweasel, 127) means and they won’t negotiate Trust Expressions. When Iceweasel sends both (iceweasel, 127) and (iceweasel-xx, 127) in its trust_expressions extension, this isn’t enough for country XX to force the use of their CA. The server (assuming that it has a cert issued by the government CA and a second one that is trusted worldwide) when running the algorithm in section 6.4 [2] has multiple matches and gets to choose which one to use: “If multiple candidates match, the subscriber picks its most preferred option.” Country XX could mandate that Iceweasel advertise (xx, 1) instead of (iceweasel-xx, 127) so that pre-deployed certificates match, but again nothing forces the server to use that cert instead of the globally trusted cert. Country XX would have to mandate servers implement a technical mechanism to prefer their CA over other ones, and this mechanism is not one that Trust Expressions provides. Mandating such a mechanism would be a similar amount of technical work on servers to mandate support for selecting the government issued cert in the presence of the certificate_authorities extension. I posit that the action that results in a browser bifurcating their root store is the point in time at which they are compelled to adopt a new CA that does not comply with the CA/BF requirements or other root program policies. If a browser is compelled to trust a CA that meets all root program requirements, I imagine it would trust said CA globally instead of going through the engineering work to support different roots in different regions. In [3], you describe a 5-step plan that supposedly is likelier to happen with Trust Expressions than without Trust Expressions. If we assume that the government CA complies with all root program and CA/BF requirements, meaning that it does not mis-issue certificates, then it is trusted globally by a client and Trust Expressions plays no role in its deployment. Therefore, for this to be an issue that is enabled by Trust Expressions, I conclude that at some point in your 5-step plan, the CA “turns” and begins to mis-issue certificates. If the CA starts to mis-issue certificates early in its rollout, then every certificate issued by this CA will be viewed as suspect and there is no opportunity for MitM certs from this CA to hide among valid certs, as they are all considered MitM certs. If the CA waits to mis-issue certificates until after it is trusted globally, then Trust Expressions played no role in its rollout. We’ve seen something like this happen before [4]: a government CA is trusted in a root program, it mis-issued a certificate, and then it was distrusted. Your example step 1 could occur in the same way, with some government coercion of server operators to support it, and Trust Expressions plays no role in the deployment of this certificate. Trust Expressions does help in minimizing the damage when performing the distrust. In steps 3 through 5 of your plan, it appears that the political arguments for requiring the government CA depend on making some sort of security argument. I only see steps 3 through 5 being successful if the CA is still honest at this point in time. If the CA is honest, the browser has no reason to fragment its trust store, and Trust Expressions played no role in its deployment. This scenario looks identical to how a government would get a CA deployed today without Trust Expressions. What point in this process depends on Trust Expressions - that is to say, at what point does a browser decide that the government CA is acting differently enough from the other CAs in its root store that it’s willing to fragment or bifurcate its trust store, and after that point, how does the politics play out that mandating this CA’s trust is still somehow legitimate? In your latest message [5], I understand the context of governments pushing for inclusion of certain roots with varying degrees of legitimacy. I don’t see the on-ramp for CA pre-distribution being meaningfully different with Trust Expressions compared to certificate_authorities. For the shared fate of each browser having a single international trust store, I see Trust Expressions cutting both ways. If we assume that the pressure from a government to coerce trust in some roots is so great that other countries’ interest and pressure to prevent it does not stop that government and the root program bows to pressure, then Trust Expressions allows balkanization and limits how many clients are impacted by this insecure outcome. I don’t want to see the balkanization of the Web PKI and this is an undesirable outcome, but if faced with the choice between keeping a single global root store for a browser (which makes everyone insecure) or bifurcating the trust store (so only users affected by that government’s mandate of insecurity are insecure), I personally would choose the latter. There are clearly many geopolitical factors that go into how and whether other countries would pressure this government that is pushing for an interception root CA to be included. I’m a novice when it comes to geopolitics, so I don’t know how the availability of technical mechanisms (e.g. Trust Expressions or the certificate_authorities extension) will impact those discussions. Cheers, Nick [1] https://mailarchive.ietf.org/arch/msg/tls/vZG881PcoXfn43iuRP2bQUeB1V4/ [2] https://www.ietf.org/archive/id/draft-davidben-tls-trust-expr-03.html [3] https://mailarchive.ietf.org/arch/msg/tls/XW2tkA2Bk9Rj9RpQM36q044ggHo/ [4] https://security.googleblog.com/2013/12/further-improving-digital-certificate.html [5] https://mailarchive.ietf.org/arch/msg/tls/3JYfN_ahb_N-yEZir-feCFOxCJk/
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
