[dns-operations] DNSSEC DANE testing

[Vernon Schryver]

> From: Paul Wouters <paul at cypherpunks.ca>

> I put up the xpi as well, you can grab it at:
> http://people.redhat.com/pwouters/mozilla-extval-0.7.xpi

I see no queries for TLSA records for nohats.ca, fedoraproject.org,
or dane.rd.nic.fr from Firefox after installing the xpi file on
FreeBSD 9.0, Windows 7, Centos 2.6.32, or Ubuntu 11.10.


>                                                ... You should see this:
> https://nohats.ca/dane.rd.nic.fr.png

I can't see that just now (Aug 23 19:10:43 UTC) because my resolver
is saying SERVFAIL about nohats.ca unless I set the CD bit.
http://dnssec-debugger.verisignlabs.com/nohats.ca
says "None of the 1 RRSIG and 3 DNSKEY records validate the DNSKEY RRset"
"alpha.bebout.net/71.19.151.18 returns REFUSED for nohats.ca/SOA",
"None of the 1 RRSIG and 3 DNSKEY records validate the A RRset"
and so on.
http://dnsviz.net/d/nohats.ca/dnssec/ knows about the DLV but says 
something about the DNSKEY having "Status: bogus" 13 hours ago.


> stating: "Domainname is secured by DNSSEC, and TLS proved the certificate
> is valid (and no CA)" Obviously, if you have a signed cert by a trusted
> CA, it will tell you that instead. Note TLSA validation is marked with
> purple.  (both https://nohats.ca and https://dane.rd.nic.fr work for me)

I hope I misunderstand, because that sounds to me like the error that
was in the Chrome support for its notion of a predecessor to TLSA.
Giving precedence to CAs trusted by the browser would conflict with
the "MUSTs" for all of the certificate usages in section 2.1.1 of RFC
6698.  Letting the HTTP server say how its certificates are validated
is secure only in the Chinese Great Firewall men-in-all-of-the-middles
sense.

To belabor the obvious (never mind that it did not occur to me when
I read the description of the Chrome mechanism), a man in the middle
that wants TLS signatures on modified web pages would replace the
certificates from the real HTTP servers its own certs signed by CAs
that it controls.  The replaced certs would lack the magic stamp
for the Chrome mechanism and the CA cert would be in the steaming
pile that came from your browser vendor.  A proper DANE implementation
detects that attack unless the adversary has replaced the DNSSEC
trust anchor in your trusted DNS resolver.


Vernon Schryver    vjs at rhyolite.com