1412691 - Allow static pinning of DS records

Status: UNCONFIRMED

(Core :: Security: PSM, defect, P5)

Description

[github]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20171024165158

Steps to reproduce:

Feature request, depends on bug 672600 being implemented.


Actual results:

Static Key Pinning for TLS certs is likely to be removed from Chrome and I suspect from FireFox and I always though that solution was flawed, but the problem is real.

The problem is that the security of a TLS certificate requires trust that authoritative DNS servers upstream of the zone has not been compromised.


Expected results:

If the DS records that a DNSSEC secured zone has to submit to their upstream zone (usually the TLD) can be preloaded into FireFox then when FireFox uses DANE to authenticate the validity of a TLS certificate, it can reject the connection if the DNSSEC records for the zone do not validate with the pre-loaded DS records, similar to how static public key pinning currently works.

This way, should a DNSSEC signing key upstream of the zone be compromised, it could not be used to create fraudulent TLSA records that are fraudulent but that FireFox would validate.

I would personally recommend only banks and other high risk MITM targets use static DS records in FireFox but the option should be there for those kind of zones.

Comment 1

[github]

Just in case my explanation wasn't clear.

Example.com runs a bank and uses DNSSEC with a TLSA record to secure their x509 certificate.

A hacker manages to get the .com private DNSSEC signing key.

The hacker can then use the .com private key to create a fraudulent DNS records for the example.com zone that would validate with DNSSEC by creating their own signing keys for the example.com zone, and signing the DS fraudulent DS records for the zone using the valid .com DNSSEC key the hacker obtained.

These fraudulent DNSSEC records could then be used as part of a MITM attack (e.g. coffee shop, hotel, or other open wifi networks) and FireFox would not know they were fraudulent.

However if example.com had their valid DS records preloaded in FireFox then FireFox would reject the fraudulent DNSSEC records because even though they validate, they do not use the DS record that FireFox has preloaded for the example.com zone.

Trust that the DNSSEC signing keys for .com and the root server have not been compromised are thus taken out of the equation.

The drawback of course is that it makes rotating the KSK for the example.com zone more complicated, but it would have no effect on the difficulty of rotating the ZSK or the TLS certificates. Since KSK (and thus DS records) are usually rotated less than once a year, the increased difficulty is worth mitigating the risk for frequent targets of MITM attacks.

This is better that static key pinning, btw, as static key pinning encourages the reuse of private keys used for the actual encryption of sessions between the server and user. With the DS record being what is pinned, the server can change their private key for TLS every single day if they wanted to (that would be absurd but they could).

Comment 2

[github]

I think this would also be a solution to the problem described here : https://www.theregister.co.uk/2017/10/30/mozilla_mistrust_dutch_ca/

If governments are influencing CAs and requiring them to issue fraudulent certificated for TLS certificates, DANE keypinning that does not require trust of the TLD would allow those domains to be secure from government snooping regardless of what influence a government has over the CA or TLD.