Greetings! I've read through both drafts and the full thread on list and do not support adoption.
My primary concern is that I'm afraid that shifting the burden to a place where it will not be picked up will result in a lower use of TLS. This is one of the concerns highlighted in Jackson's draft that we will have a hard time understanding as that population does not attend our meetings or participate in this list. ACME helped us go from about 30% adoption to 90+% and we have a small gap that remains. The approach could do more harm than good, lowering the percent of adoption of TLS on the Internet by making it too difficult for distributed administrators to maintain. The expected level of expertise limits the adoption as it is not possible for all orgs to hire highly skilled resources. I'm also not in favor of adopting the draft with the idea it may be abandoned as was discussed on thread. I'd prefer more brainstorming up front so as to not cause harm and reduce security to a group that doesn't have the resources to keep up. The following point in Dennis' draft is also compelling: "Section 5. The Path Forwards ... The proposed use cases for trust negotiation for intermediate suppression to help enable the transition to post-quantum is the single compelling use case. However, there are several alternative mechanisms that have already been proposed, including one which has already been adopted by the TLS WG, and all of which are much simpler and easier to implement, will not bifurcate the TLS ecosystem between browsers and non-browsers and do not entail the risks of the abuse of trust negotiation. The next section of this draft explores those alternatives and compares them to TAI." We already have an adopted draft for the post-quantum use case and this TIA draft has that as its most compelling use case. Thank you. I think more work needs to be done first. On Wed, Jan 29, 2025 at 4:46 AM Bas Westerbaan <bas= 40cloudflare....@dmarc.ietf.org> wrote: > 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 > -- Best regards, Kathleen
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
