589538 - Browser-side validation of DNSSEC information

Status: RESOLVED WONTFIX

(Core :: Networking, enhancement)

Description

[Neil Harris]

DNSSEC is generally aimed at protecting resolvers from false DNS information. 

A truly paranoid browser implementation should be able to verify DNSSEC information itself, in order to ensure end-to-end security that is not vulnerable to man-in-the-middle attacks by malicious external DNS resolvers.

This could take two forms:

1 Automatic validation of _all_ DNS information where DNSSEC records are available, and indication of whether any given piece of DNS information has been validated

2 Attempting to do the above only when validation is specifically requested by a DNS resolution API

In either case, existing internal DNS APIs will need to be modified or extended in order to add this new functionality.

Comment 2

[Patrick McManus [:mcmanus]]

from duplicate bug: for DNSSec signed DNS records, verify the signature and provide feedback to the UI for at least the different cases of trusted, broken, and expired.

Apparently signed-but-expired is expected to be a fairly common case so it
should be treated less aggressively than broken-signature.

Comment 3

[Leen Besselink]

You do understand that expired keys for DNS-information should not be used, it could be forged.

If you really do want to do that, I suggest keeping a cache and if what is in the cache is the same as what the current DNS-information says, you could use it.

And setting a limit on the amount of time it should still be used. Maybe if the limit is really short (< 24 hours ?), I guess you could use the expired keys to validate the DNS-information.

Comment 4

[Neil Harris]

Perhaps it's overkill to list specific server certificates, given that they will expire and be replaced. How about listing the identity of the top-level CA that issued the certificate instead?

For example, https://google.com uses a certificate signed by "Thawte Consulting (Pty) Ltd." which can be traced back to "Verisign Class 3 Public Primary Certification Authority", which is in Firefox's root store. 

Instead of the certificate itself, one or both of these organizational **names** could be stored in Firefox's cache of high-profile certificate identities. This would then allow any number of certificate changes and expiries to pass, so long as Google kept on using the same CAs that traced back to the _same_ stored root certificate as before. It might possibly be worth storing and checking the same certificate validation path.

If at some later date, the state of Elbonia (or someone who had hacked one of that nation's CAs) attempted a MITM attack on Google users, and https://google.com offered up a certificate signed by (say) "Republic of Elbonia State Certificate Authority", even though that might (quite validly) be in Firefox's root cert store, it could still be recognised as an unusual change, and presented as a security warning to users, eg:

> ** WARNING **
> google.com is presenting a certificate signed by "Republic of Elbonia 
> State Certificate Authority", when it would usually present a 
> certificate signed by "Verisign Class 3 Public Primary Certification
> Authority". This may indicate that someone is trying to tamper with this
> connection. ...etc, etc...

Yet, on the other hand, the Elbonian State Television site, even though it is signed by the very same root "Republic of Elbonia State Certificate Authority" CA we just rejected above, would pass, either by being explicitly listed for that site, or no entry at all being listed for that site.

Comment 5

[Neil Harris]

Just one more note: unlike DNSSEC, this would work even if someone (just hypothetically, but not impossibly) managed to compromise the DNSSEC root certificate or the signing certificate of another major player in the DNSSEC hierarchy, which would (as far as I understand it) effectively render all DNSSEC's security guarantees useless.

Comment 6

[Neil Harris]

Oops: comment 4 and comment 5 were aimed at an entirely different bug, and should be there instead of here. Please ignore them here.

Comment 7

[Robert]

Attachment: tarball of 4 patches to add dnssec support

Bug 748232 adds support to NSPR for local DNSSEC validation using DNSSEC-Tools' libval. These patches adds DNSSEC validation to firefox using this new NSPR functionaility. Patches are against fairly recent mozilla-central code base.

Comment 8

[Patrick McManus [:mcmanus]]

dnssec is fragile, slow, and doesn't effectively authenticate the web content. So its just not a good match.

tlsa (dnssec as a pki for https) is a possibility unrelated to closing this bug.

Comment 9

[jbash]

Where is the roadmap for DANE (the more widely used name for TLSA)? Is there a bug open for it? How would you expect to implement it without the underlying DNSSEC infrastructure?

You're right that DANE is the only real reason for a browser to do DNSSEC, but there are bunch of people out there spreading half-informed anti-DNSSEC and anti-DANE FUD, while offering "alternatives" that would either be complementary or deal with entirely different problems. Those people have gotten traction with other browsers, notably Chrome. So it would be nice to see some sign of support.

Comment 10

[Neil Harris]

DANE is _absolutely_ the use case for this. I see this as complementary to Let's Encrypt / observatory approaches.

Anyone who can mess with non-DNSSEC DNS can probably also mess with packet transport, so DNSSEC by itself doesn't help -- but the combination of DNSSEC and DANE can present an alternative to CAs. Sure, now you're potentially vulnerable to your DNS provider, but that's a vast improvement on being vulnerable to every CA in the world, which was the case before. Note also that your DNS provider could also potentially screw with things like Let's Encrypt, if they wanted to (albeit at substantial risk of being caught doing it later), so that's not a panacea either.