> > 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. >
Sorry, I meant to address this point as well. The difference between TE and the certificate_authorities extension, is that there's less widespread server support for the latter. You might compel a browser to bifurcate and advertise the certificate_authorities extension, but pushing out server-side support would be a substantial challenge. Not speaking for Google, but I believe their intention /is/ to put in the substantial work to make server-side TE support ubiquitous, such that it would be a minor ACME config change On Fri, May 24, 2024 at 4:00 PM Brendan McMillion < brendanmcmill...@gmail.com> wrote: > 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
