Earlier quoted context omitted.
I'm pretty sure the SCT requirement contained the blast radius of this compromise to avoid anyone from actually being affected by it, so your comment doesn't really follow here. Also, DANE relies on DNSSEC [1], which is bad. https://sockpuppet.org/blog/2015/01/15/against-dnssec
Ah hello 2015, my old friend. DNSSEC is a Government-Controlled PKI -> Not if the root of trust is secured by a proof-of-work blockchain DNSSEC is Cryptographically Weak -> Not if zone operators upgrade to ECDSA as defined for DNSSEC in https://tools.ietf.org/html/rfc6605 DNSSEC is Unsafe -> NSEC3 is mentioned by the article itself DNSSEC is Expensive To Deploy -> We can make tools for this, so much has gotten easier…
https://tonyarcieri.com/on-the-dangers-of-a-blockchain-monoc...
https://paragonie.com/blog/2017/07/chronicle-will-make-you-q...
> Not if zone operators upgrade to ECDSA as defined for DNSSEC in https://tools.ietf.org/html/rfc6605
First: That's a big "if". Lots of RSA legacy support.
Furthermore, ECDSA is so bad that Ed25519 and Ed448 are even coming to FIPS 186-5 later this year.
Citing ECDSA adoption in DNSSEC doesn't make as strong of a case as you might think.