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
