[Cryptography] DNSSEC = completely unnecessary?

[Ralph Holz]

Hi,

> DNSSEC specifies the *intent* of the domain owner. A validated lookup
> tells you which of the 160 CAs is the chosen one. It's the domain
> owners' responsibility to run a monitoring script to detect rogue
> DNS-registrars that send out wrong data, and publicly sentence those to
> the internet death penalty.

First, DNSSEC != DANE-TLSA != CAA. The latter is about pointing to the
intended CA (as an identifier string), although TLSA can also do the
same (as the hash value of a root's public key). DNSSEC is about the
integrity of any RR.

Second, what seems to be often missing in the discussion is the
consideration of synchronising TLSA records and the certificate-in-use.
I don't subscribe to the view that this is very easy -- if scans of the
HTTPS and SSH ecosystems have shown anything, then it is that poor
deployment practices are to be blamed for a huge part of our problems,
and none of DNSSEC/DANE/CAA solve those.

E.g. I recently did a scan of SSHFP records for all known hosts serving
SSH (this is a very short description of the process). 94% were
accurate. Fine for SSH -- but 6% failed resolutions would be a huge
problem for the Web. So what I'm saying is: the consideration of how to
fail on TLSA errors (soft? hard?) is a hard one for browser vendors. (I
think the RFC for TLSA defines it, actually, but that's the RFC only)

> If you don't trust your chosen CA, ie, it might be coerced to sign a
> fake cert by an 'authority', create your own Root Key (on a smart card)
> and use that for your server certificate.

You may find your browsers rejecting it - because I don't see movement
among browsers anywhere to move away from the CA model towards a
TLSA-only model.

> The thing that is important is that the browsers must NOT look at the
> 'trusted' CA-list anymore!

Not buying this in its entirety, either. You're forgetting about
governments being able to take control of zones, and issue rogue RRs.

Ralph