[dns-operations] DNSSEC DANE testing

[Paul Wouters]

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.

Paul