Hi, This took a while to pull together, but Dennis has just published a fairly comprehensive look at the question of trust negotiation:
https://datatracker.ietf.org/doc/draft-jackson-tls-trust-is-nonnegotiable/ This is a response to the proposal to improve trust negotiation in TLS, in particular draft-beck-tls-trust-anchor-ids-03. There’s been a lot of bits spilled on this topic already, generating far more heat than light. It is an important question to examine though, albeit one that is broader than we typically engage with here. The conclusion in the draft, one that I support, is that trust negotiation in TLS is not worth it. It’s not just that fundamental changes to the system aren’t really justified, it’s that the change will do more harm than good. There seem to be three broad goals being considered for trust negotiation: 1. Make it easier for site operators to find compatible certificates. 2. Make it easier for root programs to implement security improvements. 3. Smooth the transition to post-quantum certificates. Trust negotiation allows sites to split the client population up. Each can then be addressed with different certificates, according to different policies. Divide and conquer. However, it’s unclear how this approach could actually improve security. Meanwhile, it seems to have as much potential to harm compatibility through fragmentation as it does to help it. In the recent interim, the PQ certificate deployment thing was identified as a bit of a distraction. Or maybe PQ was a shiny reason to care about what is really a fairly mundane set of operational problems. The most compelling problem here seems to be that some clients aren’t being updated with new trust anchors. (No really, stop doing that. The Internet is so hostile that updating isn’t a choice; it’s a necessity.) Anyhow, being able to segment that population of clients off seems like it would make it easier for clients and root programs to implement new policies without having to worry about compatibility, while giving site operators the ability to give old and new clients different certificates. Dennis’s analysis lays out how this isn’t a straight win-win situation as proponents claim. Rather, the two constituencies are in competition and enabling negotiation shifts a lot of the responsibility for the operational work of maintaining compatibility. CAs and root program operators do less work; website operators do more. For all that the system is a source of constant pain for some people, that’s because it is an important system. That system strikes a balance between the equities of multiple groups: end users, website operators, CAs, and client developers/root program operators. I list these in this order in the spirit of the priority of constituencies [1] as I believe applies to this domain. That order reflects the size of each group and the technical resources they can deploy, recognizing that larger groups with lower resources are less able to deal with operational complexity. Shifting compatibility work onto site operators is not the right answer when there are so many more of them, with far less ability to deal with these complexities. Big operators might win out, but small ones will not, even if automation might eventually help. This is partly due to the need to coordinate closely with DNS configuration in the proposed design. The design is as fair an approach as any I can conceive of, but we’ve already seen how hard that coordination is with ECH [2]. That’s rough, because any benefits that come from negotiation require lots of deployment. Otherwise, clients that want to distrust a CA can’t be sure that a site that doesn’t support negotiation uses that CA: if the site can’t negotiate, then the client is stuck with the existing distrust process (which is unpleasant, but mostly not for reasons that have technical solutions). Most of the arguments in favor of trust negotiation seem to depend on cross signing not being a thing. Cross signing addresses most, if not all of the compatibility concerns raised in support of trust negotiation. The benefit of cross signs is that it is a burden that only affected CAs incur, modulo the performance cost that comes with longer chains. The draft examines these claims and evaluates existing and new solutions for those. A lot has been said already about risks on the list. I’ll just say this: in effect, the intersection of all root programs is the only root program that matters. Maybe that’s what concerns people, but I consider that a critical feature. Trust negotiation might spur the creation of new root programs, which is a part of that risk (see the draft for a restatement of the arguments about Westphalian-based interventions that you have already heard), but not the whole of it. The big risk for me is that it undermines the common value that comes from that program intersection, including the tension between root programs [3]. When security advances happen, eventually everyone gets to share the benefits. Trust negotiation loosens the ties that force root programs to cooperate. More root programs or less cohesion are both risks that come from this. With the question of adoption of draft-beck-tls-trust-anchor-ids we’re really asking for a verdict on trust negotiation as a mechanism. The design is somewhat immaterial here. Rather, it's a question of whether there are benefits that can be obtained and whether the risks are justified. Personally, I can see a bunch of problems, but I don't see those as technical problems with technical solutions. Dennis' draft uses more words to reach the same conclusion. It seems like there is no shortage of highly emotive discussion on this mailing list of late. So I am hoping that it is fortuitous that this email goes out now. That might give people less of a sense that a response is needed urgently. Personally, I’m taking a month off and will not be checking this thread in that time. (In case you might feel like I'm ignoring you: I am, but it's not personal, I'll be ignoring everyone.) Thanks, Martin [1] https://w3ctag.github.io/design-principles/#priority-of-constituencies — being a TAG member for a year, quoting this document is now habitual. Please excuse me. [2] https://www.cyberciti.biz/media/new/cms/2017/04/Its-not-DNS.-There-is-no-wayits-DNS.-It-was-DNS.jpeg [3] ... _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
