2014-04-11 21:55 GMT+02:00 Dan Williams <dcbw@redhat.com>:

I think the big issue for me is the use of "trusted" in the proposal.
What does that actually mean? Who is doing the trusting?

The goal is to have DNSSEC validation in a system-wide, dedicated code, trusted for that purpose; i.e. unbound does DNSSEC validation for every application, with a centralized configuration and cache, so no application needs or should do this on its own; it can simply consult the AD bit in the reply.

Does it mean
that Firefox can "trust" the local caching DNS server,

Yes, for the purposes of DNSSEC validation and making sure the AD bit is set correctly..

and if so, why
would that server be any more "trustworthy" than the upstream nameserver
delivered to you by DHCP?

The upstream nameserver is often not under the control of the owner of the computer, so it can't be trusted to return the DNSSEC validation status in the AD bit correctly, and the communication channel (e.g. ethernet or unencrypted wifi) allows an attacker to spoof the reply from that upstream nameserver anyway. In the general case, DNSSEC validation needs to happen on the same machine that relies on the results of the validation.

If it
does do something, does that something break hotspot or portal detection
and login?

Not necessarily, and probably not. The applications are still in control of what to do if the AD bit is not set (e.g. because DNSSEC validation fails because the hotspot has replied with an unvalidated redirection); so, in this case, Firefox would probably not be willing to use the hotspot-spoofed DNS response as an indication of the correct public key via DANE, but it should still be perfectly willing to make a HTTP connection, including HTTP connection to "google.com" that redirects it to https://hotspot-owner.com .

Mirek