I'm not sure that this is a productive framing: "we’re really asking for a verdict on trust negotiation as a mechanism". Trust anchor negotiation is already deployed. It takes the form of chain building, cross signing, and/or client fingerprinting. At the interim, the presenters went through many of their past experiences where this system has not worked very well. There was general consensus that /something/ should change to improve the situation. So the question is whether that "something" should be a deeper reconsideration of the "chain building" approach, or an incremental improvement on it.
Specifically on the point of "most of the arguments in favor of trust negotiation seem to depend on cross signing not being a thing" -- cross signing was briefly discussed at the interim, with the conclusion being that the necessary client-side logic was too often implemented in a buggy or unreliable way. If the wg decides to pursue an incremental improvement of chain building, we'd need to accept that baggage and have a plan to improve chain building's reliability. Happy holidays On Sat, Dec 21, 2024 at 5:27 AM Martin Thomson <m...@lowentropy.net> wrote: > 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 >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
