The privacy properties are still what's documented in the draft: there is still a separation between stuff you request unprompted and stuff request in response to an active server hint. Unprompted, only request the stuff common to your anonymity set, e.g. all instances of a particular browser version, etc. Others you might choose to only reveal after an active request, whether it's DNS or retry, e.g. user-specific additions or removals.
Giving more options for the unprompted mode, or even removing the DNS thing, doesn't change this. We still have room for both by virtue of the retry. Though, sure, this could be an argument for keeping the DNS thing in the toolbox, if some application wants a user-added root to be gated on an active request and to do so on the first round trip. On Wed, Apr 15, 2026, 06:25 Ben Schwartz <[email protected]> wrote: > What are the privacy properties of this arrangement? > > If the client is expected to expose all of its trust anchor groups in its > ClientHello, unencrypted, this would seem to mark clients with distinctive > additional trust anchors for passive surveillance and tracking. This seems > like a loss of privacy when compared to the DNS-triggered approach, which > requires an active attack to probe for additional trust anchors. > > --Ben Schwartz > > On Wed, Apr 15, 2026 at 4:06 AM David Benjamin <[email protected]> > wrote: > >> Hi all, In the discussion around https: //github. >> com/tlswg/tls-trust-anchor-ids/pull/104, originally centered on >> landmark-relative Merkle Tree certificates, I realized this was probably >> worth describing more generally in the PR (since updated) >> Hi all, >> >> In the discussion around >> https://github.com/tlswg/tls-trust-anchor-ids/pull/104, originally >> centered on landmark-relative Merkle Tree certificates, I realized this was >> probably worth describing more generally in the PR (since updated) and >> here, as it’s more broadly useful than the original focus. >> >> So, as a brief recap, Trust Anchor IDs had a few parts: >> * Short OID-based IDs to replace overly long X.509 names >> * An inverted authenticating-party-offer / relying-party-select flow >> driven by DNS >> * A retry mechanism to mitigate signaling errors >> >> This gives a series of building blocks, depending on the application's >> needs. If the application didn’t have too many IDs to send, it can just >> send them all and move on. If it already had selection heuristics, it could >> apply those heuristics and lean on the retry to fix signaling errors, etc. >> If the application just has an undirected mass of IDs to send, it could use >> a DNS hint to help the client send the right initial request, with all the >> fun that entails. >> >> The idea with the PR is that IDs can just as easily represent groups of >> trust anchors. All we need is for the CA-provided certificate metadata to >> say not just the trust anchor ID, but also containing group IDs. Originally >> it was trying to express some property of landmark-relative Merkle Tree >> Certificates (SomeCA.42 also implies SomeCA.41, SomeCA.40, etc.), but it >> also could express groups like: >> >> * Versioned groups of the CAs operated by some CA operator >> * Versioned groups of the CAs trusted by some root store >> * Other groups one might define >> >> In a PKI where the RPs and CA metadata both are aware of some group (or >> series of groups), the RP can use the group's ID as a stand-in for >> individual IDs. Details on how that works are in the PR. In particular, >> there’s a very nice alignment between the retry mechanism, and >> SCTNotAfter-style removals that make what was once a messy version skew >> problem basically moot. It's also only a change to the authenticating >> party's evaluation function. The core TLS extension itself is unchanged. >> >> I think this can be a useful building block, and in particular, should >> give enough room to let RPs avoid the DNS mechanism. (The PR doesn't yet go >> as far as removing the DNS mechanism. We can keep it defined as yet another >> available tool for folks that might want it, or we could remove it if we >> don’t think it’s worth keeping around. I figure resolving that can be a >> later thing.) >> >> David >> _______________________________________________ >> TLS mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
