[TLS] PKI dynamics and trust anchor negotiation

[David Benjamin]

Hi all,

There's been a lot said about root store divergence and fragmentation. We
discussed this quite a bit in the interim, but with the continued interest
in the topic, and some arguments being brought up on repeat, I wanted to
clear some misconceptions, in a separate thread to avoid cluttering the
main one.

First, to correct a misrepresentation: this draft is not a veiled attempt
to completely diverge from the Web PKI and fragment the ecosystem. Section
7.6 is not "guarded language" to this effect. That simply does not make
sense on even a technical level. TAI is not needed to enable this.
Negotiating a few private CAs is easy. The existing certificate_authorities
extension works just fine to enable the hypothesized harmful fragmentation,
yet this has not manifested. Rather, this draft is trying to meet the needs
of existing public PKIs, with their independently-maintained but
vaguely-common large lists of multi-vendor CAs.

As for Section 7.6, I wrote that text. It was describing how non-browser
clients can have different needs from browsers, as folks in this WG
frequently bring up the importance of non-browser-centricity for TLS. It
doesn't name specific example players simply because I think doing that in
an internet draft is disrespectful.

Having spent my whole career on user security in this space, when things go
wrong, it's common to hear, no, fixing this will cause this other distant
bit of infrastructure to fail! If users on the web and this critical
infrastructure truly have such different needs, our systems should have the
tools to reflect that, instead of pitting them against each other. Indeed
several root programs are already moving to purpose-specific PKI
hierarchies. PKIs translate an application's security and deployment needs
into policy and trust anchor choices. When the underlying needs are truly
different, it will naturally be reflected in PKI requirements.

And then there's the unavoidable time-based divergence. Clients last
updated a year ago will only reflect what happened then. PKIs make
subjective predictions about external entities ("I think this CA will only
sign correct things"). These predictions can and do go wrong. When they do,
clients must change, and we need a transition strategy. Old clients will
fall off as they upgrade, but across the whole Internet, it takes time. We
cannot just declare them non-existent, or demand that other services stop
supporting them. And we've heard from server operators in the interim that
the existing tools, including cross-signs, aren't sufficient for their
needs. The interim discussed these dynamics in more detail, and the
consequences of continuing to pit security and availability against each
other, rather than letting them work together.

So those are instances of small, yet impactful divergences that exist
today. I think what people are concerned about is broad, unnecessary and
rampant divergence. But two clients of comparable type and age (e.g. two
up-to-date browsers) diverging for the sake of differentiation is not
anyone's interests. All the incentives here remain. Clients do not want it
to be difficult to serve them. That shared goal is itself the reason for
this work. Giving server operators the tools they need to weather some
divergence will not suddenly make it viable to maintain hundreds of
certificates for every client and every locality. That means there remain
reasons to align. And, to reiterate, a client wishing to use a private PKI
already has the tools to negotiate it in TLS.

There's also been talk of moving the ecosystem forward together, but
allowing faster-moving clients to clear security issues is what enables
risk-averse clients to follow. With or without TAI, if client A disables
TLS 1.0 or removes a bad CA, no amount of fate sharing will make client B
more secure. What makes client B more secure is them mirroring the change.
The sooner that change sticks in A, the more the rest of the ecosystem will
be compatible with it, which makes it easier for client B to match. That
lets the transition complete more quickly and reduces this time-based
divergence. Tying the faster clients to the slower ones doesn't bring the
slower ones forward. It slows the whole ecosystem down.

All this is a dynamic we've explored throughout TLS. It's the story of all
parameter negotiation. We need the lever for transitions and for the cases
where needs truly differ, but we still face pressures to keep the
variations in check. We've never treated PKIs as different here. We had a
CA list in CertificateRequest in SSL3 through TLS 1.2. We had ClientHello
trusted_ca_keys in RFC 4366 and renewed in RFC 6066. We generalized the CA
list to certificate_authorities in RFC 8446. We had a whole interim on the
topic and reaffirmed this.

As we all established at the interim, it does not make sense to sacrifice
both security and availability, out of fear that somehow limiting trust
anchor negotiation to closed ecosystems is what stands between open

[TLS] I-D Action: draft-ietf-tls-keylogfile-03.txt

[internet-drafts]

Internet-Draft draft-ietf-tls-keylogfile-03.txt is now available. It is a work
item of the Transport Layer Security (TLS) WG of the IETF.

   Title:   The SSLKEYLOGFILE Format for TLS
   Authors: Martin Thomson
Yaroslav Rosomakho
Hannes Tschofenig
   Name:draft-ietf-tls-keylogfile-03.txt
   Pages:   15
   Dates:   2025-02-04

Abstract:

   A format that supports the logging information about the secrets used
   in a TLS connection is described.  Recording secrets to a file in
   SSLKEYLOGFILE format allows diagnostic and logging tools that use
   this file to decrypt messages exchanged by TLS endpoints.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-keylogfile-03.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-keylogfile-03

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: PKI dynamics and trust anchor negotiation

[Salz, Rich]

First, to correct a misrepresentation: this draft is not a veiled attempt to 
completely diverge from the Web PKI and fragment the ecosystem.



I never said that the draft is such a veiled attempt, and I don’t recall any 
other postings saying that.  I am concerned that the fragmentation is a highly 
likely outcome.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption Call for Trust Anchor IDs

[David Schinazi]

I support adoption.

I personally agree with the consensus from the trust tussle interim - I do
think we should work on the problem as described. Not that that opinion is
particularly relevant, because the consensus has already been declared by
the chairs anyway. On that note, I haven't seen new information that would
warrant reopening that consensus call. I found the trust-is-nonnegotiable
draft to be well-written -- though perhaps heavy on the amount it was
citing the TAI draft -- but I did not find information in it that hadn't
already been said or written on the topic so far.

Now that we agree that we want to work on that problem, I think that TAI is
a reasonable starting point. I find it more compelling than other ideas
discussed in this thread, such as extending HSTS. I agree that this space
might have risks, but as we iterate on that solution, I trust in our
collective ability to design something that solves the problems and
mitigates those issues.

Thanks,
David

On Wed, Jan 15, 2025 at 8:01 AM Joseph Salowey  wrote:

> At the trust tussle Interim in October we had consensus that the working
> group was interested in working on the following problem:
>
> “Avoid client trust conflicts by enabling servers to reliably and
> efficiently support clients with diverse trust anchor lists, particularly
> in larger PKIs where the existing certificate_authorities extension is not
> viable”
>
> After IETF 121, we asked for submissions for possible working group
> adoption as a starting point for this work. We received two submissions:
>
> [1] Trust Anchor Identifiers, draft-beck-tls-trust-anchor-ids-03
> 
>
> [2] Trust is non-negotiable, draft-jackson-tls-trust-is-nonnegotiable-00
> 
>
> [1] defines a new protocol mechanism, while [2] provides an explanation of
> why the mechanism in [1] may not be needed and may be problematic. Since
> the second draft does not define a protocol mechanism we are not
> considering it for adoption, but we request that working group members
> review both documents and use [2] as input into determining whether we
> should adopt [1] as a working group item.  Adoption as a working group item
> means the working group has change control over and can modify it as
> necessary; an adopted document is only a starting point.  Please respond to
> this thread if you think the document should be adopted as a working group
> item. If you think the document is not appropriate for adoption please
> indicate why.  This adoption call will close on February 7, 2025.  Also
> please remember to maintain professional behavior and keep the discussion
> focused on technical issues.
>
>
> Thanks,
>
>
> Sean, Deirdre and Joe
>
> ___
> 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

[TLS] Re: PKI dynamics and trust anchor negotiation

[Watson Ladd]

Dear David,

I have to start by apologizing. It's not until now on reading your
email that I've come to the realization of what the issues were with
at least the early negotiation proposals in a way that makes them
clearly articulateable, and I think earlier on it would have been more
fruitful for me to have realized them. I've also not necessarily fully
digested the latest proposal.

If we were to have used certificate_authorities to negotiate, every
client would be sending a list of all the authorities it recognized,
servers would intersect them with what they had, and sending back the
result or an error if there were none, perhaps with some indicative
information of what they had on hand. In this world a new client would
be just as able to send such a list as any other, and servers could
recognize shifts in support and change the set of CAs they use
accordingly. There would be no additional mechanism inflected penalty:
if server A and client B can connect, they are able to determine this
fact, regardless of whatever deviations from commonality each one has
in their contribution.

A negotiation where what is advertised is an inherently opaque
pointer, and where each side must maintain an idea of what that could
mean, does not have this property. Servers have to explicitly act to
support the new identifier by getting a configuration that includes
it. Whether or not this is indirectly away as part of ACME doesn't
really change the equation. New clients can't count on server support,
unless they advertise an already existing value. There's been various
ways to express deltas to try to solve this, but they all involve
paying a penalty for deviation.

We've been through this before with the web platform looking more at
feature detection than painful UserAgent sniffing as browsers keep
telling all sorts of lies on top of lies.

There's also the fact that we've gone back and forth about how to
negotiate parameters, regrouping the possible dimensions a few times
and in different directions. We also have to deal with OS stores; this
bit us with TLS 1.2 where the set of supported algorithms had to split
out leafs from the rest of the chain since different implementations
could be used. I'm not sure that starting off with a tight coupling of
a bunch of dimensions is the right idea, but don't feel as strongly
about that.

The dynamic I'm worried about most then isn't fracturing: as you point
out there are some countervailing forces where people want easy
support. Rather it's that we artificially drive up the price of
picking different CAs than the dominant implementation.

Sincerely,
Watson

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: PKI dynamics and trust anchor negotiation

[David Benjamin]

On Thu, Feb 6, 2025 at 4:40 PM Salz, Rich  wrote:

>
>
> First, to correct a misrepresentation: this draft is not a veiled attempt
> to completely diverge from the Web PKI and fragment the ecosystem.
>
>
>
> I never said that the draft is such a veiled attempt, and I don’t recall
> any other postings saying that.  I am concerned that the fragmentation is a
> highly likely outcome.
>

Hi Rich,

This was not in reply to you specifically. :-p

As for why fragmentation is not a likely outcome, the rest of the message
(not in your quoted portion) addresses this directly. Did you have any
specific thoughts here?

David
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption Call for Trust Anchor IDs

[Salz, Rich]

I've thought about this for a while, and had intended to not say anything, 
although I (doubtless because of my employer :) have been lobbied by advocates 
on both sides.

I am opposed to adoption. While I can believe that there are real-world issues 
that this solves, I feel the risk of fragmenting the WebPKI far outweighs the 
gains. The days of "Best viewed in IE" are behind us and I don't want to 
introduce "Only Secure with EdgeFox" which I think is a highly likely outcome 
from this.

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org