It is silly that in today’s world, we consider it good enough that a server can send a client an end entity cert and a grab bag of intermediates and cross signs and tell the client “I hope there’s enough material here for you to build a path to something that you trust”. If someone proposed a new system to this working group that relied on a server sending a grab bag of extra certs, without any assurance that a path to something the client trusts exists in all that goop, and wasting 10s of KB of bandwidth in the handshake, I would oppose adoption and wonder how someone would think that’s an acceptable design and what sort of unstated constraints lead to that design.
This is the system we have today with X.509. We can and should do better. Moving past X.509 will be a long process, but it is something that I and others [1] think we should do. The syntax of X.509 isn’t the only problem though - X.509’s system of path building and cross-signs is what got us to this point of throwing a grab bag of certs over the wall and praying that it works. To fix this problem, we need trust anchor negotiation. If this working group rejects trust anchor negotiation, it is saying that this is an acceptable design. I would be disappointed to see the working group that created TLS 1.3 a decade ago decide now to reject trust anchor negotiation in favor of X.509’s very rudimentary trust anchor agility. We agreed at the interim that we want to solve this problem, yet people on this thread opposing adoption of draft-beck-tls-trust-anchor-ids are repeating the same arguments against trust anchor negotiation that were presented at the interim without presenting new information. On the technical side, most arguments against trust anchor negotiation center around cross-signs. Many people have pointed out [2][3][4][5] that we have reached the limit of what we are capable of doing with cross-signs. I believe the experience of server operators over the arguments in draft-jackson-tls-trust-is-nonnegotiable when it comes to the capability of cross-signs. Cross-signs (and path building) can only do a strict subset of what a trust negotiation mechanism like TAI can do. For the specific use case of migrating to PQ, a classical/PQ cross-sign is a waste of bandwidth that provides no security value [6] and is a bad design for the migration. Another argument raised against trust anchor negotiation is that it shifts the burden of compatibility work from root programs and CAs to site operators and end users. This assumption is predicated on a large amount of root store divergence, site operators using TAI in a non-automated fashion, or a mistaken assumption that TAI’s success requires mass adoption by websites. Wide deployment of TAI is not a requirement for TAI’s adoption by the working group, and for the use case of divergent trust stores, TAI is most useful for the site operators who have found through experience the limits of cross-signs and are already managing and deploying multiple distinct certificate chains to serve their diverse client populations. In many cases, servers doing this need to use TLS fingerprinting to identify clients, so TAI reduces the burden for these server operators. For server operators who currently get a cert from a single CA, deployment of TAI should change nothing for them. To (mis)quote Obama, “If you like your [cert chain], you can keep it”. As long as our RSA X.509 PKI continues to exist and be used on the web, I don’t see a high risk of divergence between root stores. The same roots that have existed since the SSL was first used on the web will continue to be ubiquitous (or new roots cross-signed by them), and site operators can choose to get certs from those CA operators. Opponents of trust anchor negotiation have described two broad categories of risk that it could introduce. One is the risk of malicious root store behavior [7], and the other is the risk of losing common value from root program intersection [8]. Out of respect for the chairs’ request to keep the discussion focused on technical issues [9], my only statement on malicious root programs is that whether this is a risk depends on the hypothetical non-technical behavior of various entities outside this working group, and to opine on whether those risks exist would be speculation and improper for this discussion thread. The common value of root program intersection comes in two forms. One is when root programs collectively agree on requirements for CAs and browsers, e.g. through the CA/Browser Forum, and set the floor for requirements CAs must meet. I assume this is where the tension between root programs mentioned in [8] comes from. As stated in [8], when security advances happen here, the benefits affect everyone. The other form of common value is when a single root program takes unilateral action to impose new requirements on CAs in its program. These unilateral actions have little effect on the security for users of other root programs’ browsers, as their security is determined by the weakest security practices across all CAs in that root program. Ultimately, each root program has its own independent policy, and participation in this tension between root programs is voluntary of browsers. Even enforcing the CA/BF baseline requirements is up to the browsers individually, in that root programs have to individually remove CAs when they fail to meet the baseline requirements. Given the voluntary nature of participation, I see no reason why TAI and diverging trust stores would result in less cooperation between root programs to improve security for their users. In summary, I am unpersuaded by the alternatives to trust anchor negotiation and TAI, nor am I persuaded by the described risks. I support adoption of draft-beck-tls-trust-anchor-ids. 1: https://mailarchive.ietf.org/arch/msg/tls/jD3iJOdXQuyjyjAxy5MhClBAYOg/ 2: https://mailarchive.ietf.org/arch/msg/tls/xlHH85qzZowtlO5yQQ0jzWoxoyc/ 3: https://mailarchive.ietf.org/arch/msg/tls/CLzChdOrUMKm3dJazXRiaWmZhf8/ 4: https://mailarchive.ietf.org/arch/msg/tls/ALAx6musgbK4WGqD9Jv6QWgwd1c/ 5: https://mailarchive.ietf.org/arch/msg/tls/ihyUKPdlHARky3v1IWu27DUkiMw/ 6: https://mailarchive.ietf.org/arch/msg/tls/Fjf_kKdLNwP5K8fi9-F6Ci-DI9Q/ 7: https://www.ietf.org/archive/id/draft-jackson-tls-trust-is-nonnegotiable-00.html#name-to-what-end 8: https://mailarchive.ietf.org/arch/msg/tls/JZl0U7gKNYn1FWVFjzlL-qZXzF8/ 9: https://mailarchive.ietf.org/arch/msg/tls/3wTgK3ga4YYISGIV0X1fCpZKT50/ On Tue, Feb 4, 2025 at 5:29 PM Dennis Jackson <ietf= 40dennis-jackson...@dmarc.ietf.org> wrote: > It will not come as a surprise that I oppose adoption for the reasons laid > out in 'Trust is non-negotiable' [1]. > > The claims that Trust Negotiation can improve security or compatibility > just do not stand up to scrutiny. Especially as in over a year since first > introduction, there has been no credible proposal for how TN could be > deployed outside of browsers and major CDNs or how it could bring any > benefit at all with such a limited scope for deployment. It's not like > major CDNs struggle to offer certificates suitable for browsers. > > Even if the deployability concerns could be solved and so Trust > Negotiation enabled at scale, then it would cause much more harm than good. > Managing one certificate chain and CA relationship is already painful for > many website operators, but TN would compound that pain by allowing root > programs to diverge and placing the onus on website operators to obtain and > manage multiple certificate chains to ensure compatibility with each root > program's clients. > > It would also be a major abuse vector for users, who are much more likely > to suffer than benefit from the resulting fragmentation of the WebPKI, as > well as being put at risk by use of TN to establish new root programs with > malicious or negligent stewardship (domestic PKIs, enshittification, > ossification). > > In both cases, the result is a claimed reduction in operational burden for > root programs and major CDNs (who have the most capacity and expertise to > handle it) and the very material transfer of risk and complexity to users > and website operators (who are least well equipped). > > As technologists evaluating a proposal that would alter the architecture > of one of the Internet's most critical ecosystems, we owe users and website > operators better. > > Best, > Dennis > > [1] > https://datatracker.ietf.org/doc/html/draft-jackson-tls-trust-is-nonnegotiable > > > > > > ---- > > Below the fold, some comments on the discussion so far: > > > *On Cross Signing * > > The current solution to trust anchor agility is path building / > cross-signing. [...] I firmly believe that path building is unsalvageable. > In addition to the interim discussions, this blog post [2] by Ryan Sleevi > was very convincing to me. > > I read Ryan's blog post and came to some very different conclusions. > > Doing path building 'right' was a problem solved a very long time ago in > browsers and many other implementations. Implementations that still aren't > getting it right today simply don't care about the problem enough to fix > it. If they did care, they would just fix their implementation, as indeed > OpenSSL had already done 2 years before Ryan's blog post was published. > > Your argument rests on the idea that someone not doing path building > correctly today would be willing to do the extra work of implementing TAI > (including the necessary API changes and DNS integration) and would > implement it correctly, but would be unwilling to make the smaller and > simpler changes to fix up their path building implementation. This doesn't > make much sense. > > > *On coming PKI transitions * > > My interest is particularly in the WebPKI space, where annual removals of > web trust bits starting this year will make finding common trust amongst > clients an exponentially harder problem over time. > > Looking at the kind of time its taken to get TLS 1.3, QUIC, ECH and other > standards into the wider world, I think this perspective is extremely > optimistic. No matter what, root programs are going to be managing the > coming root transitions exclusively with cross-signing. > > *On dealing with issues post-adoption* > > 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. > > Once the code has shipped, the genie doesn't go easily back into the > bottle. There's a right time to address these issues and that's as early as > possible. > > [2] > https://medium.com/@sleevi_/path-building-vs-path-verifying-the-chain-of-pain-9fbab861d7d6 > > > > > _______________________________________________ > 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
