On 11/06/2024 02:24, Devon O'Brien wrote:
Focusing on the actual draft text, the TLS trust expressions extension
does not represent any kind of major paradigm shift, primarily due to
its strong similarity to the existing certificate_authorities TLS
extension. [...]
There is no fundamental capability offered by trust expressions that
isn’t already available by certificate_authorities. When compared to
certificate_authorities, the primary obstacle being addressed by trust
expressions is the size of the message sent in (1). X.501
distinguished names are notoriously verbose, and modern trust stores
contain hundreds of trust anchors, rendering it infeasible for relying
parties to dedicate tens of thousands of bytes in a TLS handshake to
listing trust anchors. Notably, parties that may wish for clients to
signal a specific mandated CA can do so efficiently with
certificate_authorities today, as this requires sending only a single
distinguished name.
There are a number of issues with this argument. The first and most
important is that you are misunderstanding and so misrepresenting the
concerns that are being raised.
We have been discussing on the list whether Trust Expressions enables
bad actors (in particular, governments) to establish their own root
programs and get users and websites to adopt them. This is a distinct
scenario from the case you addressed where a government demands the
inclusion of a specific single government CA. Although both are equally
bad for the security and privacy of users.
As previously discussed on the list, government root programs are much
more dangerous proposals than the forced inclusion of specific CAs
because they appear to have legitimate purposes in the eyes of
lawmakers. Proposals to mandate the inclusion of a single government CA
in existing root stores are as transparently evil as the plot of the
average bond villain. The community understands there is no legitimate
reason a government should force inclusion of their CA and so infers the
actual use case will be mass surveillance or censorship.
The more attractive route for governments is to argue that they are
establishing a domestic root store (or 'trust regime'). The government
will establish a regulator to manage the scheme and approve the suitable
CAs. These domestic root stores are argued to enable digital
sovereignty, break free of control by American big tech and help build
the local cybersecurity industry. Despite being dressed up in this
clothing, they are just as effective tools for surveillance and
censorship as forcing a CA into an existing root store would be.
One of the key differences between Trust Expressions and the
certificate_authorities extension is that T.E. is a very effective tool
for establishing a new trust store and indeed has been designed with
this goal in mind (see bold text below). It is not only the fact that
T.E. compresses the certificate_authorities extension that enables this
outcome. Another key design decision is letting the CA decide which root
stores a website should support, without needing a decision or approval
from the website operator.
The second issue with the argument that Trust Expressions does not
introduce new risks is that the certificate_authorities extension only
exists on paper rather than in running code. If a government were to try
to pass some legislation which used the certificate_authorities
extension, they would be completely unable to enact it in practice. This
is because support in TLS libraries is practically non-existent. Most of
those I surveyed did not have any support, a couple had support but only
for client certificates. I was unable to find any library or webserver
which supports certificate_authorities in the client_hello although
presumably one exists. As the certificate_authorities extension has
been standardized for 6 years now and support is still so limited, I'm
not especially concerned that will change in the future.
I also want to be clear that there is no danger in writing down ideas
like the certificate_authorities extension or Trust Expressions.
Governments are capable of these ideas even if they tend to execute them
with limited technical competence. The danger entirely comes from
whether running code, out there in the real world, actually supports
these features. Governments, even powerful federations, would find it
impossible to force certificate_authorities or Trust Expressions into
popular TLS stacks if the community were against it. But if we ship
these features to the entire web, they can (and will) be abused.
Summing up:
* Certificate_authorities does not enable the creation of domestic
root stores, trust expressions does by solving their adoption
problem (expanded on here [1])
* Domestic root stores have the same (or worse) harms than simply
mandating a government CA in existing root stores.
* Domestic root stores are much more likely to be supported by
(non-technical) lawmakers than mandating inclusion of government CA
in an existing root store.
* Separately, support for the certificate_authorities extension has
not shipped and its getting the code running that governments need
in order to enable the abuse, not the ideas in draft specs.
Devon O'Brien wrote:
Discussion about whether some root program may be pressured to accept
national trust anchors that do not meet existing standards is a
critically important security policy topic, but is fundamentally
orthogonal to this mechanism. Drawing causality between trust
expressions and this outcome (especially ignoring the existing surface
already provided by certificate_authorities) may be well-intentioned,
but is misplaced.
Bob Beck wrote:
Someone could also decide we really really want to start their own
root program, for <reasons>. Maybe they don't want to be what a major
browser is. *One of the (unstated, and perhaps we should state it
clearer) goals of trust expressions is to allow for new root
programs to be created.
*
I agree with Bob that Trust Expressions enables the creation of new root
programs and hope that the other authors of Trust Expressions would also
agree. If so, it cannot be argued that these risks are in any way
orthogonal, rather, they directly concern how this goal / feature can be
exploited by bad actors.
My point has been that the actors with the incentives and the
capabilities to establish new root programs are mostly governments who
are interested in surveilling and censoring users. I am less optimistic
that T.E. will enable the creation of new root programs for good reasons
- that would require websites go through extra effort to support
multiple CAs simultaneously without a legal stick pushing them to do so
- otherwise the new root program could simply be a strict subset of the
existing root programs and not need T.E.
Nick Harper wrote:
If you're talking about the EU eIDAS QWAC trust list, those CAs were
already trusted by browsers before the eIDAS regulations took effect,
and eIDAS allows for their distrust and removal. Already, one CA [1]
on that list is being distrusted by multiple [2] browsers [3]. Even if
the EU has a published list of CAs that they could turn into a trust
store manifest, this is a distraction from the point that with TE,
abuse requires the cooperation (or compulsion) of more parties than
with certificate_authorities.
I think we're getting rather away from the point, but to clear up some
factual errors:
* About one third of the eIDAS QWAC trust list were also in browser
root stores. The remaining two thirds were not trusted.
* eIDAS does now have safeguard to enable removal that were added at
the last minute due to outcry [2] [3].
* The fact the EU has a domestic trust store ready to go is very
material as to whether Trust Expressions can be used to ship a
domestic root stores to web users. You seemed to be imagining this
would be rather abstract and a lot of work compared to a single
government CA, rather than something that has already been done and
heavily debated in Parliament.
David Benjamin wrote:
Broadly, the fingerprinting story is the same as the
certificate_authorities extension, in that trust expressions targets
the cases where the trust anchor list is common to your desired
anonymity set, whatever it is.
The draft doesn't currently mention the risks here and I think quite a
bit more analysis is required. Especially as certificate_authorities is
not used by any major implementation today in the Client Hello, so the
risks cannot be hand waved as similar to what we have today.
I think its probably reasonable to assume that the major browser
fingerprints will always have distinct TLS fingerprints. However, Trust
Expressions adds an additional fingerprinting vector as different Chrome
versions will have different trust labels, making it easy to pick out
older Chrome clients. Additionally, different derivatives of Chrome,
e.g. Chromium, Edge, etc will also now be possible to fingerprint
through their trust store. It is presumably likely that things might go
even further, e.g. with being able to fingerprint an Android Webview vs
a Chrome TLS Client Hello based on which root store is used or if
different root stores are offered for different channels or geographies.
This seems like quite a substantial increase in fingerprinting risks
compared to existing extensions, which tend to reveal only whether they
are in use, rather than directly leak information about who is using them.
Best,
Dennis
[1] https://mailarchive.ietf.org/arch/msg/tls/XW2tkA2Bk9Rj9RpQM36q044ggHo/
[2] https://scotthelme.co.uk/what-the-qwac/
[3] https://eidas-open-letter.org
_______________________________________________
TLS mailing list --tls@ietf.org
To unsubscribe send an email totls-le...@ietf.org
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
