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
