[TLS]Re: Trust Anchor Negotiation Surveillance Concerns and Risks

[Mike Shaver <[e-mail]>]

On Mon, Jul 22, 2024 at 1:36 PM Dennis Jackson <ietf=
[e-mail]> wrote:

> I would like to hear from the authors (or others in the TLS implementation
> community) if they think Trust Expressions / Trust Anchors can be pushed
> into non-browser endpoints by default and the work they think would be
> required to achieve it?
>
> I think I see how, with substantial investment, an application like a
> browser could adopt these designs. I'm not sure I can see a TLS library
> ever being able to offer it by default.
>

Today, TLS libraries used in “general purposes” systems, like the default
HTTP libraries or such for languages, have a pretty simple model of trust:
list of certs, each with notBefore/notAfter/eku at best. Already that lags
behind some of the nuance that web browsers use, whether Mozilla’s simple
notBefore-of-issued-cert measure, or Chrome’s more complex SCT time
validation.

As an example, the popular Python package “certifi” provides a set of
“curated” roots, which is actually the Firefox root set. When Firefox
stopped trusting certificates issued by “e-commerce management” after a
certain date, that package removed the root entirely, meaning that unlike
with Firefox (and Chrome), all previously issued certificates were also
rejected.

We’re in the early days of these “bounded trust” capabilities, and I have
some hope that we will settle into a small number of additional rules that
are sufficient to make root distrust (or scope reduction) easier on the
ecosystem. At that point, libraries like OpenSSL will need to decide if
they want to be able to reflect the web PKI (as interpreted by at least one
browser, anyway), in which case they will need to add these sorts of
checks, and root store providers will need to configure them. Maybe we end
up with a standard language for expressing them, but root stores already
differ in format today without much pain, so I don’t think that’s
necessary. I think that most program authors who use these “standard” TLS
implementations are generally expecting to validate as a browser would,
unless they take additional steps, so I see this lack as a bug in those
libraries, or at least a capability that needs to be easily available in
each stack ecosystem.

Trust Anchor negotiation will require configuration of both sides, but so
does cipher negotiation and so forth, and I think that it will be fine for
a library to come with “sane, web-like” defaults, and then provide a
mechanism for configuring alternative policies when desired.

Whether it should be or not, especially given recent events, it’s generally
easier to get a configuration change deployed than a software update. But
also, even if the legacy endpoints never get a trust anchors configuration
update or support, those that *do* support it can be treated appropriately
without disrupting the frozen clients. This would let modern clients like
browsers continue to tend to the web PKI, without the opposing force of
such possible disruptions. From my experience with root programs, this
would be a very welcome capability!

Mike