>
> 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

Reply via email to