On Wed, Aug 14, 2024 at 5:10 PM Michael Richardson <mcr+ietf@xxxxxxxxxxxx> wrote:
Most of our issues with TLS and CAs is really the market failure on the
browser side of things. We don't have TLSA/DANE support in browsers (or
IPv6-LL) because we have a lack of choices.
We (as a planet) don't understand that we need to spend money on maintenance
of software. The 81% that was Mozilla's take from Google ought to wake us
up.
Not an IETF issue, sadly, though.
That was a problem of the DANE group's own making.
There was a group at Google that was interested in putting means to authenticate certificates in the DNS that had the ability to see the scheme deployed in the browser:
The certificate entries were removed when the draft moved into PKIX becoming CAA so as not to conflict with DANE. But the DANE group did not take note of the differences between the drafts and insisted on an approach that the Chrome group had rejected.
I am not sure if I can fully remember the subtleties of the issues and which were mine and which were the Chrome teams. But the big issue for Chrome was always speed of resolution because THEIR ANNUAL BONUSES DEPENDED ON IT. So the CAA scheme was very carefully constructed so that it would not increase the resolution time. Another major difference is that DANE is certificate publication where CAA was certificate authentication. Finally, CAA does not require DNSSEC while DANE joined itself to at the hip.
A few years later, we had the exact same farce with DPRIV where the group decided they could get to market fast by adopting TCP quickstart rather than building on UDP as I had proposed three years earlier. So instead of doing the job right, they built on a standard that requires a kernel level modification(!) and TO SAVE TIME(!!!)
Of course we now have DNS over QUIC but a decade later.
