> From: Paul Wouters <[email protected]> > 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 [email protected] _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
