Unsurprisingly, I support adoption. To recap from the interim where we took on this problem, server operators need to be compatible with all their supported clients, while clients need to curate accepted certificates to maintain user security.
This client function is security-critical: accepting a wrong name/key binding enables that key to intercept TLS. Clients cannot just check a name/key binding from first principles, so they delegate to PKIs: elaborate systems of trusted keys, trusted operators, expiration, revocation, delegation, etc. These systems are inherently dynamic. To trust a CA is to predict its future behavior, which is inherently subjective. Sometimes those CAs are found untrustworthy, and clients must act to preserve user security. Beyond that, as the working group often discusses, different clients have different needs. Not everything looks like a browser. Those different needs influence how the client interacts with a PKI. This naturally leads to diversity, across different clients and different versions of the same client. From the interim, supporting this, with today's PKIs and today's tools (including cross-signs), is not easy for server operators. The result is a conflict between security-critical PKI maintenance, and keeping a service available to users. Both goals then suffer, thus the motivation to solve this problem. Trust Anchor IDs applies TLS's standard, well-understood approach to these problems: parameter negotiation. It is a retool of certificate_authorities, a similar, longstanding mechanism dating back to SSL 3.0. It is widely deployed in client certificates PKIs, but is not ideal for existing, larger PKIs. Trust Anchor IDs tries to meet those existing PKIs where they are, and TLS's usual style of solution. At the same time, it is not specific to one PKI. Not everything is a browser. I think this is a good starting point for the working group. My coauthors and I are eager to start working on it with you all. As with other drafts, we very much expect that this too will change after adoption, perhaps significantly. (E.g. discussion over how to approach tradeoffs between DNS vs. unhinted ClientHellos.) This is a large solution space, and navigating it in a working group document lets us do so reflecting the group's consensus. As for the draft arguing not to solve this, gosh, coming up on ten years of contributing to this community, I don't think I've ever been quoted so much! Unfortunately, it largely misrepresents both what's in our draft and the motivations discussed at the interim. I'd rather not follow this pattern of quoting and trying to dispute each sentence at length. Speaking for myself, I am exhausted by the tenor of discussion that produces, and am eager to move on to a more productive stage of this process. I think more effective would be that we discuss any specific topics on the list that folks may be interested in. Thanks all! David On Wed, Jan 15, 2025 at 11:00 AM 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
