Oh, I should have added: I put together an informal "explainer"-style document to try to describe the high-level motivations and goals a bit better. The format is adapted more from the web platform end, which likes to have separate explainer and specification documents, but it seemed a good style for capturing, at a high level, what we're trying to accomplish. https://github.com/davidben/tls-trust-expressions/blob/main/explainer.md
It's largely a copy of the start of this email thread, but I figured it'd be useful to have a more canonical home for it. (We'll probably adapt some of that text back into the draft, after some more wordsmithing.) On Thu, Feb 29, 2024 at 7:18 PM David Benjamin <david...@chromium.org> wrote: > Circling back to this thread, we're now looking at prototyping the TLS > parts in BoringSSL, on both the client (Chrome) and the server side. Let us > know if you have any thoughts on the proposal! > > (Nothing that would prevent us from changing details, of course. But as > there are a lot of pieces here, we'd like to get some experience with > things.) > > On Thu, Jan 25, 2024 at 5:00 PM David Benjamin <david...@chromium.org> > wrote: > >> Hi all, >> >> Now that the holidays are over, I wanted to follow up on >> draft-davidben-tls-trust-expr and continue some of the discussions from >> Prague: >> >> >> https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html >> >> >> https://datatracker.ietf.org/meeting/118/materials/slides-118-tls-tls-trust-expressions-00 >> >> First, I wanted to briefly clarify the purpose of excluded_labels >> <https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html#name-trust-expressions>: >> it is primarily intended to address version skew: if the certificate is >> known to match (example, v10) and the client says (example, v11), the >> server doesn’t know whether v11 distrusted or retained the CA. We resolve >> that with a combination of excluded_labels and TrustStoreStatus. >> excluded_labels is not intended for user-specific removals. I’ve >> reworked the Privacy Considerations >> <https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html#name-privacy-considerations> >> section to discuss this more clearly. >> >> Second, I wanted to take a step back and try to better articulate our >> goals. I think the best way to look at this draft is in three parts: >> >> 1. A new multi-certificate deployment model (the overall goal) >> >> 2. Selecting certificates within that model (the TLS parts of the draft) >> >> 3. Provisioning certificates (the ACME parts of the draft) >> >> We’d most like to get consensus on the first, as it’s the most important. >> Trust expressions are a way to achieve that goal, but we’re not attached to >> the specific mechanism if there’s a better one. We briefly discuss this in >> the introduction >> <https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html#name-introduction>, >> but I think it is worth elaborating here: >> >> The aim is to get to a more flexible and robust PKI, by allowing servers >> to select between multiple certificates. To do this, we need a way for the >> servers to reliably select the correct certificate to use with each client. >> In doing so, we wish to minimize manual changes by server operators in the >> long run. Most ongoing decisions should instead come from TLS software, >> ACME client software, and ACME servers. >> >> Why does this matter? PKIs need to evolve over time to meet user security >> needs: CAs that add net value to the ecosystem may be added, long-lived >> keys should be rotated to reduce risk, and compromised or untrustworthy CAs >> are removed. Even a slow-moving, mostly aligned ecosystem is still made of >> individual decisions that roll out to individual clients. This means, >> whether we like it or not, trust divergence is a fact of life, if for no >> other reason than out-of-date clients in the ecosystem. These clients could >> range from unupdatable TV set-top boxes to some IoT device to a browser >> that could not communicate with its update service. >> >> Today, the mere existence of old clients limits security improvements for >> other, unrelated clients. Consider a TLS client making some trust change >> for user security. For availability, TLS servers must have some way to >> satisfy it. Some server, however, may also support an older client. If the >> server uses a single certificate, that certificate is limited to the >> intersection of both clients. >> >> At the scale of the Internet, the oldest clients last indefinitely. As >> servers consider older and older clients, that intersection becomes >> increasingly constraining, causing availability and security to conflict. >> As a community of security practitioners, I wish I could tell you that >> security wins, that those servers can simply be convinced to drop the old >> clients, and that this encourages old clients to update. I think we all >> know this is not what happens. Availability almost always beats security. The >> result of this conflict is not that old clients get updates, it is that >> newer clients cannot improve user security. It takes just one important >> server with one important old client to jam everything, with user >> security paying the cost. >> >> We wish to remove this conflict with certificate negotiation, analogous >> to TLS version negotiation and cipher suite negotiation. Certificate >> negotiation, via trust expressions, means security improvements in new >> clients do not conflict with availability for older clients. Servers can, >> with the aid of their ACME servers, deliver different chains to different >> clients as needed. >> >> Now, some of these problems can be addressed with cross-signs between >> CAs, but this is a partial solution at best. Without negotiation, this >> still means sending certificates for the lowest common denominator to all >> clients. This wastes bandwidth, particularly with post-quantum >> cryptography, where every signature costs kilobytes. Additionally, an >> individual server operator cannot unilaterally configure this. Cross-signs >> apply to entire intermediate CAs, not just the individual server’s >> certificate. >> >> There’s more to say on this topic, as relieving this conflict solves many >> other PKI problems and enables new solutions for relying parties, CAs, and >> subscribers. We discuss some of these in the use cases >> <https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html#name-use-cases> >> section. But hopefully this helps clarify our goals and is a starting point >> for discussion. >> >> We’d be interested to hear thoughts on these issues or others. Our hope >> is to reach enough consensus on the list to determine whether it would make >> sense to have a call for adoption around Brisbane. >> >> Thanks, >> >> David >> >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
