I support adoption of [1]. Making trust anchor negotiation an in-band mechanism is a pretty big shift for TLS. I think it's a good sign that we've taken so much time to get to an adoption call: it means we're treating the shift with the seriousness it deserves.
I think we should work on the problem articulated at the interim, and I think the trust anchor ID draft is a good place to start. I'd also like to see this get implemented sooner rather than later so that TLS servers can start thinking through how this changes their operations and whether the benefits outweigh the potential burden. (This is one of the major concerns from [2].) That said, I think we need to take our time with this. We should try to get as much feedback as we can, from other WGs and as well as stakeholders who don't regularly hang out at IETF. The final document should reflect as much risk assessment as possible, as well as any known unknowns. Like previous shifts in the TLS ecosystem, we might not know all of the side-effects of this change for another decade or so. I think the biggest risk described in [2] is that root programs might begin to diverge. MT put it nicely in a previous email: The big risk for me is that [trust negotiation] undermines the common value > that comes from that program intersection, including the tension between > root programs [...]. 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. However, while I can see how trust negotiation could make divergence easier, I don't think it makes divergence inevitable. Still, we should consider whether there are technical mechanisms we could use to help maintain cohesion among root programs. Perhaps this could be a consideration for the draft. Best, Chris P. On Wed, Jan 15, 2025 at 8:01 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
