On Mon, Jun 17, 2024 at 9:10 AM Dennis Jackson <ietf= 40dennis-jackson...@dmarc.ietf.org> 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 products with different goals and policies. One is a browser and the other is an Android platform component. It is already quite common that features will deploy differently across the two. > or if different root stores are offered for different channels or > geographies. > This is also not true. Chrome does not vary the root store by geography or release channel. While I could imagine varying by release channel as part of rolling out a risky change, varying by version seems far more likely. Even so, such rollout variation is transitory and no different from the transitory variation created by rolling out TLS 1.3 or Kyber, or any other behavior change across a population. > 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. > This misunderstands both existing TLS extensions and trust expressions. Recall that the standard negotiation pattern in TLS is a client-offer, server-select. The prototypical TLS extension will thus reveal the client preference, not just whether it is in use. For example, the supported_groups extension reveals the client’s named group preferences. The signature_algorithms extension reveals the client’s signature algorithms preferences. Likewise, trust expressions reveal the client preferences they communicate. What the privacy implications are depends on the resulting anonymity set. As discussed above, the point of the Privacy Considerations section is to give guidance on this. Indeed it specifically says not to reveal user-specific preferences. *It does not leak who is using the extension.* This is exactly analogous to how user-specific sigalg preferences will reveal user-specific information, while software-wide sigalg preferences have a more reasonable anonymity set. The difference is that trust expressions include guidance on this, while RFC 8446 has no discussion at all. David
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
