Hi Dennis, thanks for your feedback. First, you mention the issue of the possible requirement of key escrow; we don’t feel that trust expressions make this any more or less of a threat to the ecosystem. Were a government to require sites to escrow private keys, it would not matter who signed them since the escrow agent would be in possession of those private keys, and they or anyone else they give the private key to would be in the position to compromise connections using these keys. We hope we can set this point aside as orthogonal to the remaining bulk of your objections.
Second, there seems to be a concern surrounding trust expressions making it easier for root stores to diverge due to the multi-certificate model. Trust stores already diverge today. As you’re likely aware, there are very good reasons that root programs do not coordinate on trust decisions, so this is not something that will change in the foreseeable future. As root programs diverge, subscribers are (often unwittingly) forced to choose which clients to break as they try to stay within the intersection. This conflict also impacts root programs by pressuring against trust changes. The users whose security would benefit from those changes ultimately bear this cost. We don’t think that a resigned acceptance of the sharp edges of the status quo is a compelling reason to continue forgoing trust anchor agility, especially when we are faced with the need to radically change the entire landscape to accommodate PQC’s large signatures. In practice, we also don’t think this plays out such that the long tail of clients are dragged along into security by browsers and other modern clients. Instead, the state of the art is held back by the long tail. The multi-certificate model empowers subscribers with the optional ability to support divergent client trust if they choose to. As an example, one root program could adopt new post quantum roots and provide immediate protection for their users without waiting for the slowest or least-resourced client/browser vendor to follow suit. Other root programs and their clients would be unaffected by this change and could roll out the same change on a different timeline or opt for a different approach altogether. By design, a multi-certificate model removes the ubiquity requirement for a trust anchor to be potentially useful for a server operator. Your concern seems to be that this could be a way for governments to coerce one root program to include specific trust anchors and increase mass surveillance. This is an outcome that root programs, including both Chrome and Mozilla, have fought against for many years and will continue to do so. This has been a motivating force behind technologies like certificate transparency, which enables detection and response to this kind of behavior (and would continue to exist in some form regardless of trust expressions). I think we are in agreement with the severity of these hypothetical scenarios, but strongly disagree at the causality you are drawing between the existence of a negotiation mechanism and this dystopian end state. In particular, surveillance requires targeted clients to somehow trust an incorrect key for a server. If the attacker’s CA is trusted by a client, it can already sign bad keys. Surveillance only requires inclusion in the root store, it does not matter whether the attacker’s CA was also useful for server operators. Signing the correct key for a server does not help the attacker. This is why we did not add this as a risk to the draft, however we are happy to add a broader discussion of implications of root program divergence to a future version. Looking at the things we believe trust expressions does bring to the table to improve the security of relying parties: - The ability for PKIs to transition to newer root keys, instead of waiting for ubiquitous adoption of a replacement by all root programs. - The ability for TLS certificate selection to be robust enough that selection can occur entirely within the TLS library and server software. Server operators can safely add certificates for new algorithms, without compatibility risks that some client supports the new algorithm, but not the particular trust anchor. - The ability to deploy PKI improvements without conflicts from differing requirements and schedules in individual root programs and very old clients. - The ability to support everything else that does not use trust expressions, even old devices that can not / will not update, without impacting relying parties that wish to move ahead faster. - Server operators, once software is in place, not needing to be concerned about new trust expressions or changes to them. The heavy lifting is between the root program and the CA. - The ability for server operators seamlessly to deploy certificates from multiple CAs for redundancy, or to straddle disparate ecosystems. We acknowledge that achieving this level of agility requires a significant amount of design and implementation work for web servers, certificate automation clients/servers, and clients to support, but we believe the improvements called out in some of the discussion on this thread strongly outweigh these costs, especially when we remove outcomes that are not causally related to this mechanism. Additionally, while the design changes what is communicated between relying parties, subscribers, CAs, and root programs, it reuses the existing communication flows, making an incremental transition more plausible. And finally, we think this will drastically improve the ability to migrate the Internet to PQC—not just in terms of a faster timeline, but because trust anchor agility will enable the community to develop fundamentally better solutions for authentication, through reduced experimentation costs and shorter-lived roots of trust. Sincerely, David, Devon, and Bob On Mon, Apr 29, 2024 at 7:20 PM Dennis Jackson <ietf= 40dennis-jackson...@dmarc.ietf.org> 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 listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > 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
