[TLS]Re: TLS trust expressions and certificate_authorities
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 su
[TLS]Re: Working Group Last Call for Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings
> This email starts the working group last call for "Bootstrapping TLS > Encrypted ClientHello with DNS Service Bindings” I-D The draft says: " It is applicable to all TLS-based protocols (including DTLS [RFC9147] and QUIC version 1 [RFC9001]) unless otherwise specified." But the ECH draft says: "ECH is supported in TLS 1.3 [RFC8446], DTLS 1.3 [RFC9147], and newer versions of the TLS and DTLS protocols." Those two documents should be harmonized. I think they should both say what the ECH draft says, but they should also both mention that QUIC as a protocol that uses TLS 1.3 is also supported. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: TLS trust expressions and certificate_authorities
On Mon, Jun 17, 2024 at 9:10 AM Dennis Jackson wrote: > 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. > Hi Dennis, You seem to have lost the part of my message where I linked to the section in the draft. The “hand wave” was a summary of the more detailed discussion in the draft: https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html#name-privacy-considerations As to that, I think you’re misunderstanding the point of this section and the audience of a standards document. Fingerprinting risks are as much a property of how a mechanism is used, as they are of the mechanism itself. For example, TLS cipher suite negotiation is a fingerprinting risk if you use user-specific cipher suite preferences. It is much less of one if behavior is common across all instances of some software. But a protocol specification is fixed and can only define the mechanism. It is not useful to cite a point-in-time snapshot of what is deployed. After all, by that standard, trust expressions have zero deployment today and therefore contribute nothing to fingerprinting risk, even less than certificate_authorities. This is not a useful criteria. Rather, a protocol specification should discuss the privacy implications of different ways one might use the protocol, so that implementations can make good choices. In that sense, certificate_authorities and trust expressions are indeed broadly analogous: if you use them, you reveal the CAs that you chose to reveal. Thus, when you decide which CAs to reveal, you need to take that into account. The section discusses this and provides some guidance on this. If you think there is some detail, fitting the intent of the section, which we have missed, feedback is welcome. The details below, however, do not make sense here. Below, it looks like you are speculating about Chrome’s intended use of this extension. As I both co-authored the draft and work on Chrome, I don’t think we to resort to speculation here: > 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. > This is not true. Chrome is both able to push root store changes independent of Chrome updates, and does not update the root store on every major release. That means the anonymity sets are much larger than you imply, both because several consecutive Chrome versions will appear the same, and because root store updates will converge faster. The anonymity sets are more granular than all of Chrome, yes. As with any software, behavior changes will change behavior, and so during the transition there will be more variability, until things converge to the new one. (The draft text was a little sloppy on browsers vs versions, so we’ve gone and fixed that. However, that was just an illustrative example. The load-bearing text is the preceding paragraph. As I’m sure you’re aware, web browsers vary significantly in how they manage changes. A complete analysis of today’s web browser behavior would not make sense for implementation guidance.) And, of course, this difference is moot in most web browser contexts, as browsers already reveal their versions: explicitly via the User-Agent header, and implicitly by being programmable environments where probe for behavior changes is easy. In contexts where either of these is already accessible, it does not matter whether trust expressions reveal “some Chromium derivative”, “Chrome”, “Chrome 123”, or something in between. > Additionally, different derivatives of Chrome, e.g. Chromium, Edge, etc > will also now be possible to fingerprint through their trust store. > This is also not true. If you build Chromium from source, you will get the same trust store as Chrome. Other Chromium derivatives may, of course, arbitrarily diverge from Chromium. Whether it’s the trust store or cipher suite preferences, any TLS change will, of course, impact the TLS-level anonymity set. This is something derivatives already must evaluate for any change, but the section acts as guidance on this as well. > 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 > Distinguishing Android WebView and Chrome is already expected, as they’re different
