Hiya,
Having read the draft and the recent emails, I fully agree with Dennis' criticisms of this approach. I think this is one that'd best be filed under "good try, but too many downsides" and left at that. Cheers, S. On 30/04/2024 00:20, Dennis Jackson wrote:
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
OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
