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
