When this work was presented at IETF 118 in November, several
participants (including myself, Stephen Farrell and Nicola Tuveri) came
to the mic to highlight that this draft's mechanism comes with a serious
potential for abuse by governments (meeting minutes
<https://notes.ietf.org/notes-ietf-118-tls#TLS-Trust-Expressions---Devon-O%E2%80%99Brien-David-Benjamin-Bob-Beck---30-min>).
Although the authors acknowledged the issue in the meeting, no changes
have been made since to either address the problem or document it as an
accepted risk. I think its critical one of the two happens before this
document is considered for adoption.
Below is a brief recap of the unaddressed issue raised at 118 and some
thoughts on next steps:
Some governments (including, but not limited to Russia
<https://www.eff.org/deeplinks/2022/03/you-should-not-trust-russias-new-trusted-root-ca>,
Kazakhstan
<https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_attack>,
Mauritius
<https://www.internetsociety.org/resources/internet-fragmentation/mauritius-ictas-threat-to-encryption/>)
have previously established national root CAs in order to enable mass
surveillance and censorship of their residents' web traffic. This
requires trying to force residents to install these root CAs or adopt
locally developed browsers which have them prepackaged. This is widely
regarded as a bad thing (RFC 7258
<https://datatracker.ietf.org/doc/html/rfc7258>).
Thankfully these efforts have largely failed because these national CAs
have no legitimate adoption or use cases. Very few website operators
would voluntarily use certificates from a national root CA when it means
shutting out the rest of the world (who obviously do not trust that root
CA) and even getting adoption within the country is very difficult since
adopting sites are broken for residents without the national root cert.
However, this draft provides a ready-made solution to this adoption
problem: websites can be forced to adopt the national CA in addition to,
rather than replacing, their globally trusted cert. This policy can even
be justified in terms of security from the perspective of the
government, since the national CA is under domestic supervision (see
https://last-chance-for-eidas.org). This enables a gradual roll out by
the government who can require sites to start deploying certs from the
national CA in parallel with their existing certificates without any
risk of breakage either locally or abroad, solving their adoption problem.
Conveniently, post-adoption governments can also see what fraction of
their residents' web traffic is using their national CA via the
unencrypted trust expressions extension, which can inform their
decisions about whether to block connections which don't indicate
support for their national CA and as well advertising which connections
they can intercept (using existing methods like mis-issued certs, key
escrow) without causing a certificate error. This approach also scales
so multiple countries can deploy national CAs with each being able to
surveil their own residents but not each others.
Although this may feel like a quite distant consequence of enabling
trust negotiation in TLS, the on-ramp is straightforward:
* Support for trust negotiation gets shipped in browsers and servers
for ostensibly good reasons.
* A large country or federation pushes for recognition of their
domestic trust regime as a distinct trust store which browsers must
advertise. Browsers agree because the relevant market is too big to
leave.
* Other countries push for the same recognition now that the dam is
breached.
* Time passes and various local cottage industries of domestic CAs are
encouraged out of national interest and government enabled rent
seeking.
* One or more countries start either withholding certificates for
undesirable sites, blocking connections which don't use their trust
store, requiring key escrow to enable interception, etc etc.
Besides the above issue which merits some considered discussion, I would
also suggest fleshing out the use cases & problems that this draft is
trying to solve.
Firstly because its not clear why simpler solutions don't suffice. For
example, backwards compatible root key rotation could solved by signing
the new root with the old root, then using existing drafts like
intermediate suppression or abridged certs to eliminate the overhead of
both certs for up to date clients. This would largely eliminate the
problems raised around support for old devices.
Secondly the current proposal requires a fairly substantial amount of
coordination between server operators, ACME vendors, CAs, browsers and
browser providers and its unclear whether there are enough incentives in
place to actually see the folk deploy the technology in an effective
way. Sketching out a couple of key deployment scenarios and what
fraction of each population would need to embrace the technology for it
to be effective would give a lot more confidence.
On 23/04/2024 21:37, Devon O'Brien wrote:
After sharing our first draft of TLS Trust Expressions
<https://datatracker.ietf.org/doc/draft-davidben-tls-trust-expr/>and
several discussions across a couple IETFs, we’d like to proceed with
a call for working group adoption of this draft. We are currently
prototyping trust expressions in BoringSSL & Chromium and will share
more details when implementation is complete.
As we mentioned in our message to the mailing list from January, our
primary goal is to produce a mechanism for supporting multiple
subscriber certificates
<https://github.com/davidben/tls-trust-expressions/blob/main/explainer.md>and
efficiently negotiating which to serve on a given TLS connection, even
if that ends up requiring significant changes to the draft in its
current state.
To that end, we’re interested in learning whether wg members support
adoption of this deployment model and the currently-described
certificate negotiation mechanism or if they oppose adoption (and why!).
Thanks!
David, Devon, and Bob
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
