[dns-operations] DNSSEC DANE testing

Paul Wouters paul at cypherpunks.ca
Fri Aug 24 02:06:48 UTC 2012

On Thu, 23 Aug 2012, Vernon Schryver wrote:

>> 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.

I'll remake and re-release a 0.8 to ensure the version is the latest
one and will get back to the list.

>>                                                ... 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.

Yes, once again opendnssec and nsd interacted badly, and nsd's pid bug
caused nsdc to not be able to reload nsd, which caused expired RRSIGs
until I manually killed nsd and restarted it.

>> 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.

You misunderstand. Purple means "DNSSEC validated the hostname AND there
was a TLSA record, which was also DNSSEC validated and matched the
found TLS certificate". Depending on the type of TLSA record used, this
means it found the right EE-cert or CA-cert. The choice is up to the
TLSA publisher.

> 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.

It comes from DNSSEC and its validation chain, not from CAs. However,
I do not know how browsers will treat the CA industry and EV certs in
the future. My opinion will not carry any weight there.

> 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.

It seems you are upset. I do not know why. You seem to be
misunderstanding. If I had more time, I would have overlayed the
whole CA business including EV green colouring and dispensed of it.
If you know xul and can help, feel free to contact me.


More information about the dns-operations mailing list