On the surveillance risks, what differentiates trust negotiations from other existing negotiation mechanisms? Any negotiation mechanism comes with risks that it will be used to negotiate something problematic. It's not clear to me why trust negotiation is significantly different in this regard to named group negotiation, which also has a lot of relevance when talking about mass surveillance risk.
Do you see differences with trust negotiation, or in the specific negotiation mechanisms that are being proposed? Or would you have similar concerns if, say, we didn't already have named group negotiation, and were discussing adding that right now? -----Original Message----- From: Dennis Jackson <ietf=40dennis-jackson...@dmarc.ietf.org> Sent: Thursday, July 18, 2024 3:25 PM To: tls@ietf.org Subject: [TLS]Re: Trust Expressions Update On 29/06/2024 00:14, David Benjamin wrote: > We have published a second, related draft, TLS Trust Anchor > Identifiers. This draft outlines a separate mechanism we had > considered during the design of TLS Trust Expressions, and is intended > to solve many of the same problems that Trust Expressions does. Some > of the feedback we received about TLS Trust Expressions renewed our > interest in this approach. I’ve reviewed the Trust Anchors draft and although I understand the motivation for an alternative to Trust Expressions, I feel many of the same concerns with Trust Expressions around effectiveness, complexity and risk of abuse apply equally to the Trust Anchors design. I’ve produced two documents to outline these concerns and summarize mailing list conversation so far. The first [1] tackles the concerns about the risks of abuse and the second [2] tackles issues with the proposed use cases. I hope both are useful for folks wanting to come up to speed on the discussion on the mailing list ahead of the meeting next week. > We are planning to add a further document on detailed risk scenarios, > as best as we can articulate them, regarding the “surveillance and > possible future legislation” discussions on the list. This document > isn’t quite ready but we will follow up with the list when it is. I hope the mentioned summary [1] of the risks and concerns around Trust Expressions and Trust Anchors will be useful if you’re still planning to produce your own document tackling these issues. It covers the key concerns that were discussed on the mailing list, in particular, the risks of fragmenting the WebPKI, the risks of abuse for building domestic root programs for surveillance, and the impact of on client privacy by exposing the client’s root store. > We added a PKI transition strategies document with a more detailed > discussion of some transition scenarios, and how various alternatives > we have considered apply to them: I’ve tried to develop this discussion in my comments on the use cases [2]. In brief, although both drafts are positioned as solving a broad range of problems, I feel that many of the problems are quite minor and largely not well motivated. Further, examining the proposed use cases in detail suggests that both drafts rely on quite optimistic assumptions about deployment that will not be possible to satisfy in practice. I do think managing the transition to a Post-Quantum WebPKI is perhaps the most interesting problem, but as discussed in the linked comments, I don’t think Trust Expressions or Trust Anchors offers an improvement over much simpler alternatives which are already widely supported and so do not incur the complex implementation, operational and organizational challenges of these proposals. I’m also concerned that some of your comments in the explainer either misunderstand or misrepresent the existing approaches like Abridged Certificate Compression which functions quite differently to the way you claim. For those heading to Vancouver, safe travels and see you next week! Best, Dennis [1] https://github.com/dennisjackson/trust-negotiation-comments/blob/main/concerns-and-risks.md [2] https://github.com/dennisjackson/trust-negotiation-comments/blob/main/comments-on-usecases.md _______________________________________________ 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
