The risks of eIDAS did not come from the existence of a trust list, nor would they have been amplified by server adoption or negotiation mechanisms for the trust list. The existence of a trust anchor negotiation mechanism such as Trust Expressions does not change the fact that the security risk continues to be from mandated, unconditional, unrestricted trust of abusive CAs on the client, not the server. The risk of client trust in an abusive CA is not affected by the server deployment of that abusive CA, nor is it affected by a negotiation mechanism for the server to select a certificate from the abusive CA.
For those unfamiliar with eIDAS 2.0 and this topic you might want to see: - https://docs.google.com/document/d/1sGzaE9QTs-qorr4BTqKAe0AaGKjt5GagyEevDoavWU0 - https://securityriskahead.eu/wp-content/uploads/2024/02/Mozilla_-press-release_eIDAS-EP-Plenary-adoption.pdf - https://www.europarl.europa.eu/doceo/document/A-9-2023-0038-AM-007-007_EN.pdf While the latest version of eIDAS was not an attempt at mass surveillance, it was a clumsy attempt at distributed regulatory capture and “strong identity” for EU ecommerce sites without adequate controls to manage the associated risks. This proposal had the side effect of making it easier for countries to silently deploy mass surveillance via blind man-in-the-middle (MITM) attacks through legally mandated government CAs on the client. One of the available mitigations against this abuse can be found in Certificate Transparency, or at least the promise of it. Since the early legislation precluded root programs from enforcing additional controls, and QWACs are not CT logged today unless they are part of the root programs, it wouldn't have been an effective mitigation. Furthermore, since browsers may have been prohibited from distrusting the legally mandated CAs, these attacks could have gone on indefinitely. That said, as long as all certificates are logged in CT, the Certificate Transparency ecosystem remains healthy enough to deliver on its promises, and if browsers are still able to distrust CAs found guilty of abuse, we would have the ability to detect and respond to these cases. The mandated trust in eIDAS would actually be the same conditional trust applied to all CAs today, with the same risks as any other CA. The security risks from eIDAS depend on whether or not the user agent is free to enforce security requirements on the contents of the root store, including distrust, in order to prevent interception and remove CAs that fail to meet the requirements, including not to MITM. The risk is that root store trust is mandated unconditionally. It is also worth noting that RFC 7258 on preventing pervasive monitoring has been cited several times as part of the arguments against Trust Expressions. However, it clearly states: Moreover, the non-technical (e.g., legal and political) aspects of mitigating pervasive monitoring are outside of the scope of the IETF. Speculation about how a server negotiation mechanism or server deployment of an otherwise untrusted government CA might later affect a root store's decision to include that CA, and whether or not that will make it easier to then pass laws preventing the distrust of that CA, seems fully into the legal and political aspects of mitigating pervasive monitoring and has nothing to do with the technical details of the client trust store and not Trust Expressions. Ryan Hurst On Thu, Jul 18, 2024 at 12:25 PM Dennis Jackson <ietf= 40dennis-jackson...@dmarc.ietf.org> wrote: > 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
