TLS Interim 2024-10-01

Notes by: Chris Patton, Deirdre Connolly, Brendan McMillian

TLS Trust Tussle

Chris Wood

The goal is to define the problem; we won't try to agree on a solution
today.

• Primary goals

  • Availability: clients should have a cert they can use to connect
  • Security: clients should only trust legitimate certificates

• Clients have different trust stores

  • many servers on the internet support multiple certificates to
    try and provide the best one
  • some servers only have certificates for the intersection of
    all clients

• Diversity pressures

  • Some clients may move/update faster/sooner than others, nudging
    servers to support an array of certs to support a diversity of
    clients

• "The Tussle": "Avoid client trust conflicts by enabling servers to
  reliably and efficiently support clients with diverse trust anchor
  lists, particularly in large PKIS whre the certificate_authorities
  extension doesn't work"

  • Considerations
    • is divergence actually painful?
    • what's the blast radius of the operational pain? who has to
      deal with this?
    • do we only care about PQ?
    • What are the effects of deploying a solution?
    • Is the extent and duration of divergence not actually a
      widely accepted pain in practice?
    • Are forces of change (divergence) so few and far between,
      that the current distribution of operational pain seems like
      the best outcome?
    • Do we really only care about solving the PQ PKI problem,
      rather than generalizing to address types of change?
    • What are the possible downstream effects of solving this
      tussle?

• Q&A:

  • Stephen Farrell: What's the scope?

    • CAW: Focus on large PKIs, but applicable to smaller ones as
      well

  • Watson Ladd: What about feature negotiation, e.g., SCTs
    required?

    • CAW: Proposed solutions do consider this, but this isn't one
      of the core things to

Bob Beck, David Benjamin, Devon O'Brien

• The problem is increasing over time (Bob)

  • When the web was young, there was one, slow-changing trust store
  • Now we have many browsers, different trust stores of different
    "vintages"
  • "The long tail is getting longer"

• PQ is not the primary motivator for this crew

• Background (David)

  • The only way to stop TLS interception is to prevent the client
    from accepting the attacker's key

• "The Tussle" (David)

  • Over time, PKIs face pressure toward client trust anchor
    diversity.
  • As deiversity incrases, we must iethe rsacrifice security or
    availability
  • Solution: allow servers to support clients with diverse trust
    anchor lists
  • Focus on big PKIs

• Motivating examples (Devon)

  • "Changes to Google's certificates have always been painful
    because there's no negotiation about certificates in TLS." -
    Adam Langley, circa 2015

  • 2017 Seymantic PKI Distrust

    • domain validation of nearly all ceritificates from the CA
      needed to be distrusted quickly, but took months
    • details of distrust not shared publicly
    • there was a time that there was no CA that was trusted by
      all clients

  • Certificate Transparency Policy

    • In 2016, one CA (secretly) acquired another, forcing clients
      into a looser SCT policy

  • Certificate Transparency Shared Fate

    • In 2019, Google wnated to spin down original CT logs
    • Certain Apple clients constrained to rely on these logs and
      couldn't update the log list dynamically
    • Servers don't know how to differentiate old clients from new
      ones, so the logs had to stay online.
    • "McDonald's gate" had a similar root cause

  • Root Programs Diverging

    • circa 2022: a major root program has stopped accepting new
      CAs
    • 2022: Lanuch of new root program: "Chrome Root Program"
    • circa 2023: CA incident response expectaions between root
      programs are diverging

  • Post quantum

    • New PQ trust anchors will be needed: at any given time,
      there will be a mixture of clients at different stages of
      the transition
    • Clients may opt for different trade-offs to deal with bigger
      public keys and signatures

• Benefits of solving the "Trust Tussle" (Devon)

  • Better support for older clients
  • Clients can pick their own CT policies
  • CT bugs would not dictate ecosystem decisions
  • Lower bar of entry for new root programs
  • Easier for servers to support diverse clients w/o relying on
    fingerprinting

• Convergence incentives (Bob)

  • divergence is a burden for servers
  • clients are incentivized to converge

• Consequences of status quo (Bob)

  • We'll have to prioritize convergence over all other needs

• Q&A:

  • Brendan: In the Symantic case, why didn't you pursue a cross
    sign?
    • Devon: This is a PKI operator consideration; can't say
      exactly why they didn't. However, there is a "shared fate"
      problem, which might explain why they might not want to.
    • Emily: Symantec didn't cross-sign another CA because of
      potential compatibility concerns (many clients chain build
      incorrectly)

Dennis Jackson

• No divergence in the transparency logs: the same set of operators
  are trusted by all browsers
• Minimal divergence in CAs between different root programs
• CAB forum is the current mechanism for coordinating changes in the
  root stores
• Structural incentives of current system: CAs are valuable as a
  result of universal trust, and long time-to-ubiquity ensures healthy
  CAs
• Most pain from CA removal isn't technical, it is personal / legal
  pressure
• Any platform except Android version < 14 can ship automatic root
  store updates quickly
• Agility failures come from many places: quirks in TLS libraries,
  chain validation, configuration, application-specific decisions

• Implementation-defined labels to try to capture these quirks are
  just "User-Agent strings": labels were defined and not standardized.

  • Incentive to lie: less popular clients advertise more popular
    clients' agent.
  • Can give permission to other clients to stagnate

• What can we do instead?

  • Identify bugs and divergences in TLS
  • Use A/B testing to identify configuration changes

• Q&A:

  • Paul: Why do non-PQ cross-signs if they're not secure?
  • Dennis: Provides compatibility to clients that haven't trusted
    the purely PQ root first
  • Stephen: Do we have any experience as to what types of
    negotiation work?
  • Dennis: Ciphersuites work very well because ciphersuites are
    simple. When we can't really identify certain things, like
    quirks about how chain building works, that's harder.
  • David: I think we can come up with a mechanism that works for
    this. X509 and path building is a morass of complexity. If you
    think about where path building comes from, it's a way to handle
    trust anchor diversity itself. A mechanism to solve this would
    actually turn off path building.
  • Dennis: The issue with label-type approaches is that the meaning
    of the label degrades over time.

Discussion

Sean: Do people feel they understand what the problem statement is?

Kyle: On user-agent negotiation. There's many things that need to be
negotiated (trust anchor, CT, etc) There's a difference between saying
"we shouldn't negotiate any of this" versus "we need negotiation for all
of these things". Deprecating SHA-1 wasn't negotiated, and it was quite
painful. When we have the ability to negotiate, we SHOULD.

Adam: Some sharable instances of past problems we've had with
certificates:

• For a long time very copacetic relationship because we had the same
  root for a long time and then it expired. Now I have to regularly
  pick new roots.
• Many instances where we've broken more than a million devices. Then
  these devices have turned into a DoS endpoint because they retry
  loop. It often takes more than 6 months to push an update.
• We've paid a CA to issue a certificate from an expired CA to fix one
  client.
• We've had people who have lost their source code, so we've binary
  patched their software.

Dennis: It's a bad premise to start from, that we could have one
extension that will negotiate everything.

Andrew: We have a very long tail of browser clients that never update.
This has caused us to get certificates from the most ubiquitous CAs, aka
the longest lived, and this set gets smaller every year.

Stephen: Doing experiments on public data and getting more clarity over
time. If someone wanted to update RFC 5280 just for TLS, that would be
great.

Watson: Need to be very disciplined that we don't end up transforming
the problem we want to solve into a huge mess.

David: We want to focus on negotiating trust anchors.

Scott: Curious if group wants to take on problem of serving separate
certificates for PQ and non-PQ purposes?

Wayne: My life would be 80% better if we could solve half the problem:
allowing clients to signal to server what they support.

Benjamin: There have been many efforts to make government CAs. The
requirement to have a global trusted CA set has been a barrier to those
efforts.

Bas: Making the statement weaker would be helpful. It would be nice to
just know what will happen.

Responses to the Polls:

Do you understand the problem we are trying to solve (see screen).

total participants: 35
yes: 27
no: 2
no opinion: 2

Do you think we should work on this problem?

total participants: 32
yes: 24

no: 4

no opinion: ?