Last year for the interim Chris Wood asked if we could share our views on the trust tussle. After consulting with the relevant engineers, we shared the following four points.
- Today server operators have very little insight in which roots clients trust. This makes it painful [1] to move between root certificates: we learn by breaking clients, and we often don’t even discover that we break a client.From an availability and observability perspective, it would be ideal for clients to signal which roots they trust. Alternatively, [as the present draft proposes], having clients choose one chain among several installed on the server would also improve availability. - We recognise the introduction of either such a mechanism has indirect consequences, which must be anticipated and carefully considered not to decrease security and privacy. - Existing signature_algorithms negotiation is sufficient to deploy drop-in post-quantum certificates. For practical post-quantum certificates a new negotiation mechanism is likely required to signal how up-to-date the client is. Such a mechanism might coincide with those discussed above, but could well be simpler. For the balance of this email I’ll speak in a personal capacity. To start, it’s been hard to follow this email thread. Sometimes people that are close in values fight the hardest over small differences., don’t they? The intensity and absolutes uttered have made it hard to engage. Let me give it a try. Martin, thank you for sharing your thoughts in a succinct and lucid email [2]. I’ll let you enjoy the rest of your holiday. I agree on a lot of points with Martin: chiefly I agree that a vanishing intersection of root programs is an outcome that should be avoided (for more reasons than Martin states). Also I’m humming in agreement that we should put the burden in the right place, and that we shouldn’t fix something just because we can. Where the argument for the bad outcomes is unconvincing to me is that it presupposes that a trust negotiation mechanism will be deployed ubiquitously on the server-side. I simply do not see that happening. Deploying trust negotiation is hard (as Dennis indeed points out), and at the very least requires multiple certificates to be installed. Also, unless the intersection has already vanished, there is no incentive for a server operator to bother. The long tail of server operators that do not do certificate automation today will surely not adopt trust negotiation either. All root programs will need to continue to take that long tail of server operators into consideration. Recall: we’re here because long tails are hard! This is my current thinking, and I could well be missing a dynamic. I would like to see the working group think through plausible scenarios. The details of the negotiation mechanism will have an impact (eg. whether the client advertises its trust or not). Thus I feel it’s appropriate for the working group to adopt. We can always stop before standardizing, or not deploy this stuff, when it becomes clear we were wrong. Best, Bas [1] https://blog.cloudflare.com/upcoming-lets-encrypt-certificate-chain-change-and-impact-for-cloudflare-customers/ [2] https://mailarchive.ietf.org/arch/msg/tls/JZl0U7gKNYn1FWVFjzlL-qZXzF8/ On Wed, Jan 15, 2025 at 5:01 PM Joseph Salowey <j...@salowey.net> wrote: > At the trust tussle Interim in October we had consensus that the working > group was interested in working on the following problem: > > “Avoid client trust conflicts by enabling servers to reliably and > efficiently support clients with diverse trust anchor lists, particularly > in larger PKIs where the existing certificate_authorities extension is not > viable” > > After IETF 121, we asked for submissions for possible working group > adoption as a starting point for this work. We received two submissions: > > [1] Trust Anchor Identifiers, draft-beck-tls-trust-anchor-ids-03 > <https://datatracker.ietf.org/doc/draft-beck-tls-trust-anchor-ids/> > > [2] Trust is non-negotiable, draft-jackson-tls-trust-is-nonnegotiable-00 > <https://datatracker.ietf.org/doc/draft-jackson-tls-trust-is-nonnegotiable/> > > [1] defines a new protocol mechanism, while [2] provides an explanation of > why the mechanism in [1] may not be needed and may be problematic. Since > the second draft does not define a protocol mechanism we are not > considering it for adoption, but we request that working group members > review both documents and use [2] as input into determining whether we > should adopt [1] as a working group item. Adoption as a working group item > means the working group has change control over and can modify it as > necessary; an adopted document is only a starting point. Please respond to > this thread if you think the document should be adopted as a working group > item. If you think the document is not appropriate for adoption please > indicate why. This adoption call will close on February 7, 2025. Also > please remember to maintain professional behavior and keep the discussion > focused on technical issues. > > > Thanks, > > > Sean, Deirdre and Joe > > _______________________________________________ > 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
