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