> > 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?
I'll assert that many people consider eavesdropping by their own government to be legitimate, and eavesdropping by foreign governments to be illegitimate. The point at which a browser would need to make a decision about bifurcating its trust store or pulling out of a country, is the moment a government-controlled CA starts mis-issuing certificates. Without TE, browsers have no ability to bifurcate their trust store, and servers have no ability to support a bifurcated client base. So without TE, the decision must be to pull out of the country, as this is the only technically expedient solution which is acceptable to most people. With TE, browsers /can/ bifurcate their trust store, and servers /can/ support a bifurcated client base. So a decision to pull out of the country, rather than bifurcate, is simply malicious. It's also worth pointing out that the security benefits of TE (i.e., allowing rapid distrust of roots) come from gracefully handling client fragmentation that's the result of time-since-last-update, not fragmentation that's a result of different codebases. It may be worth thinking about how to rework the proposal to reflect that On Fri, May 24, 2024 at 2:46 PM Watson Ladd <watsonbl...@gmail.com> wrote: > On Fri, May 24, 2024 at 2:16 PM Nick Harper <nhar...@nharper.org> wrote: > > > > 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. > > By trust expressions do we mean the extension, or the envisioned world > where cert automation results in the CA provisioning multiple > certificates to the server via ACME extensions? I don't see why a CA > would send a cert from a competitor along with its own. This confusion > is I think contributing to the rising temperatures, coming close to > that of autoignition of IETF emails. > > > > > 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. > > 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. > > Sincerely, > Watson Ladd > > -- > Astra mortemque praestare gradatim > > _______________________________________________ > 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
