Aha, that sounds like the disconnect! One trust anchor identifier indeed only represents a one trust anchor. And, yeah, absolutely agreed that's a significant difference!
I'm guessing this mixup came from the talk of user agent strings in the problem-space-focused interm? TBH, I was quite perplexed by that. It seemed to be debating some imagined non-existent design. I tried to correct that confusion at the meeting, but clearly I didn't succeed, so let's see if I can do a better job this time and provide some background: Whether one ID is a single trust anchor or a set of them is actually the core difference between this Trust Anchor IDs design and the older Trust Expressions design. The single-anchor Trust Anchor IDs idea is actually older (you can see hints of it in earlier drafts of Merkle Tree Certificates), but sending them all at O(100) * O(5) is still a lot, and the DNS dependency was not very attractive. And so we tried a "trust anchor set" design. To be viable, the "trust anchor set" design needed to address different challenges, notably *exactly* this problem! That is the actual meaning behind the oft-misrepresented sound bite about allowing for new root programs to be created. As you correctly point out, a "trust anchor set" design would risk ossifying things on the root program side, so we wanted to be sure we mitigated this. That iteration became Trust Expressions, named after the goofy excluded_labels construction in the mitigations. But, in doing so, the result was pretty complex. I still suspect it's possible to solve that, but it's certainly tricky. And since the complexity was getting in the way of communicating the problem, we took another look at the original Trust Anchor IDs idea. This time with the realization that, even if the DNS dependency is a drag today, we'll need to solve HTTPS/SVCB automation for so many other things anyway (ECH, key-share-prediction, QUIC support). And wkech was a nice existence proof that this is surmountable. We also realized the retry flow provides some wiggle room before DNS works well. In Vancouver, the WG seemed to agree, so we changed our focus. And now there's Bas's cool encoding scheme as a third data point, which I'm very very eager to explore with you all. (I may have made peace with the DNS dependency, but I still don't like it!) With all the interesting data points here, I'm optimistic that we can find a good solution in this WG. Some thoughts on your other comments: > In that case I think you can inject it into an end-entity cert on issuance, and into the root representations in the trust store [...] Hmm, if I'm understanding you right, this sounds like the issuerTrustAnchorID idea I sketched in my previous email? Like I said, we could do if that's what the WG prefers! I just personally find CertificatePropertyList quite compelling, so it seemed worth leading with it pre-adoption. (This process has revealed a disconnect in how people treat individual drafts. For tricky trade-offs, I personally think it's most collaborative to use them as starting points, communicating important problems and interesting ideas, not finished all-or-nothing designs. That way navigating the solution can be done within the working group.) > A DNS based hint of what indication would be useful to send solves > some problems but not others. It doesn't really help servers determine > what the universe of clients is supporting and isn't that they see > without some more information. Ah yeah, this is the usual asymmetry with all TLS parameter negotiation. The side that offers a list (usually the client) only learns the final selection, while the side that makes a selection (usually the server) sees the peer's full preferences. The DNS design partially inverts certificate selection, so it's server-offer / client-select. This has a lot of nice properties (and a glaring DNS-shaped annoyance), but you're right that it flips the information available. If we stick with this aspect of the design, I think this can be managed with similar techniques as with other parameters. We do manage to reason about what cipher suites to offer in TLS clients, even though clients don't know server prefs. For example, a server that wants to answer "do I still need this certificate" can put the certificate at the end of its preference list. It can then *broadly* assume that clients picking it do so because the others won't work, and then monitor which ones are used in practice. It could even strengthen the assumption by omitting the certificate from DNS and only include it in the EncryptedExtensions retry flow, which is analogous to how clients sometimes put doomed ciphers behind a fallback[1]. (Or maybe we do something else and this is moot.) David [1] https://groups.google.com/a/chromium.org/g/security-dev/c/S9h47qPlODw/m/s_LS3FF2BQAJ On Sat, Feb 8, 2025 at 1:49 PM Watson Ladd <watsonbl...@gmail.com> wrote: > On Sat, Feb 8, 2025 at 9:44 AM David Adrian <davad...@umich.edu> wrote: > > > > To be clear, the client does NOT send its full list of trust anchors by > default. There is a server-side DNS signaling mechanism that allows the > client to pick a single anchor without sending the full set. > > > > The feedback at IETF Vancouver was to move away from a client signals, > server selects (via trust store name and version) to a server signals, > client selects (via OIDs in DNS) > > Somewhat of a side note: > > I was under the (possible mis)-impression that the trust anchor > indicator was originally an indicator of the complete set owned by the > client (which I think is what trust store name and version meant), not > one per root, vs. compressing the already existing > authorities_extension without needing a shared dictionary (which trust > anchor identifiers now does). > > While this might seem like a small difference it has a rather large > impact on the impact of clients that CAs don't care about to > implement. > > Separately: > > A DNS based hint of what indication would be useful to send solves > some problems but not others. It doesn't really help servers determine > what the universe of clients is supporting and isn't that they see > without some more information. > > Sincerely, > Watson > > > > > > On Sat, Feb 8, 2025 at 3:12 AM Bas Westerbaan <bas= > 40cloudflare....@dmarc.ietf.org> wrote: > >>> > >>> Silly clarification: the TAI identifier is just a compact identifier > >>> for the root cert, like (making it up) a 4 byte identifier? So the > >>> client sends the entire list of root certs supported, so about 100, so > >>> 400 bytes? > >>> > >>> In that case I think you can inject it into an end-entity cert on > >>> issuance, and into the root representations in the trust store. > >> > >> > >> Yeah, this is an interesting alternative design. You can reduce the > size quite a bit more with simple compression techniques. See > >> > >> https://github.com/davidben/tls-trust-expressions/issues/64 > >> https://github.com/bwesterb/go-ncrlite > >> > >> > >>> > >>> Where > >>> this doesn't work out well is on cross signs where the cert can root > >>> to multiple places/when more than one cert is needed to cover and the > >>> config only has one, but this would solve a bunch of the issues for > >>> command line programs where the trust store format is a bag of certs > >>> on disk. It could also work for cross signs since the intermediates > >>> used are known by the CA. > >>> > >>> Sincerely, > >>> Watson > >>> > >>> _______________________________________________ > >>> TLS mailing list -- tls@ietf.org > >>> To unsubscribe send an email to tls-le...@ietf.org > >> > >> _______________________________________________ > >> TLS mailing list -- tls@ietf.org > >> To unsubscribe send an email to tls-le...@ietf.org > > > > -- > Astra mortemque praestare gradatim > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
