I support adoption of [1] towards solving the problem identified during October’s interim meeting. I anticipate the shape of the solution will change in time as this group further develops the specification and acquires more information through implementation and experimentation.
As with anything new, there are deployment considerations to be mindful of and risks to take into account. [2] identifies some of those risks. It’s clear that some of the risks are serious, but what's not clear — though has been argued — is that the likelihood of those risks will change substantially based on the solution space. I personally do not find these to be compelling arguments to stop exploring this solution space this early in the process. We benefit from the IETF’s inability to do anything quickly, giving us ample time to revisit and reevaluate potential risks over time. Should [1] be adopted, I expect the WG to seriously engage with that risk assessment throughout the process. Rigorous deployment considerations are no less required than security considerations, which are table stakes these days. Finally, it’s true that the initial shape of a draft heavily influences its final shape, though I do not consider this to be a problem in practice. We are not obligated to publish anything here. This WG has abandoned plenty of adopted work items in the past, and I see no reason why we would not be comfortable doing the same here if the evidence suggests that is the best outcome for all relevant stakeholders, with preferential treatment towards end users. Best, Chris > On Jan 15, 2025, at 10:59 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
