[TLS] Re: PKI dynamics and trust anchor negotiation

[David Benjamin <[e-mail]>]

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 <[e-mail]> wrote:

> On Sat, Feb 8, 2025 at 9:44 AM David Adrian <[e-mail]> 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=
> [e-mail]> 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 -- [e-mail]
> >>> To unsubscribe send an email to [e-mail]
> >>
> >> _______________________________________________
> >> TLS mailing list -- [e-mail]
> >> To unsubscribe send an email to [e-mail]
>
>
>
> --
> Astra mortemque praestare gradatim
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>