On Thu, Aug 15, 2024 at 11:32 AM Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> wrote:
On Thu, Aug 15, 2024 at 10:46:37AM -0400, Phillip Hallam-Baker wrote:
> The registrars sold DNS names as loss leaders and made their money on
> SSL certs. So instead of driving DNSSEC deployment, DANE actually
> sabotaged it.
It is puzzling how DANE could sabotage DNSSEC deployment given there's
no deployment outside SMTP, and even in SMTP, DANE covers ~4.2 million
signed domains out of ~23 million total signed, which is out ~360
million delegated domains under signed public suffixes.
So DANE is deployed for SMTP on ~1.2% of delegated domains.
It seems in your view the DANE working group missed an opportunity to
drive DNSSEC deployment, ostensibly by specifying not only "0 0 1"
records (digest of authorised PKIX TA), but also DANE-TA and DANE-EE
TLSA records, which support private CAs or EE-only modes.
You are missing the channel conflict issue. If you tell a DNS registrar you are going to replace the product they make money on with the product they sell at cost, they are going to do their best to make sure it dies.
None of this has anything to do with connection latency. The latency
cost of looking up CAA records is not clearly lower than the cost of
looking up TLSA records.
The intended process was you would defer validation until after the TLS session was set up and abort if there was a failure. Attempts to enable that workflow in DANE were received with hostility.
My original point here is that folk complaining that browsers haven't implemented should be aware that issues were raised and the group did not care to address them.
