The Grumpy Troll

Ramblings of a grumpy troll.

Trust, X.509 PKI, DNSSEC and associated ramblings

This grumpy troll has long been miffed by the state of the X.509 trust system and the power placed in Certificate Authorities. See, for instance, https://lopsa.org/SSLIntro from October 2006; written as a guide for LOPSA members, which goes into the trust models of Kerberos, PGP and SSL's Public Key Infrastructure (PKI).

Also, a CA certificate can include nameConstraints, which restricts what names the CA claims authority over. Most CAs claim global authority and most clients don't appear to offer a way to impose name constraints by local policy instead of based on the certificate. As a result, a CA in Brazil can issue an SSL cert for www.barcleys-bank.co.uk and it's up to you to spot the mis-spelling. Equally, a British CA can issue certificates for sites under .br. This is insane.


There have been other grumblings, your humble troll can try to find which ones are on the record, but that's not the point of this post.

This troll is even more concerned that in the outcry over the DigiNotar compromise (see, for instance, LWN on *.google.com and diginotar damage disclosure, by "ioerror"), part of the resulting clamour is to migrate to a system such as DANE ("DNS-based Authentication of Named Entities"), in which DNSSEC is used to leverage the existing DNS federation system to also provide the trust anchors for the X.509 certs used to then secure data flowing to an end-point (eg, over TLS).

In The DNS root zone, international governance, ICANN and DNSSEC this troll grumped about the problems of moving to DNSSEC from the root zone and the actual balances of power in controlling the DNS, rather than what's stated on paper; I argued in favour of leaving the US government nominally in control of the root zone. But the situation is worse than this.

Various governments have tried to control what can appear in the DNS; China is infamous for its DNS proxies which ISPs in that nation are required to use, and how those proxies drop results. US government agencies have been merrily seizing domain names without judicial process, whether for gambling sites, or alleged illegal file-sharing by sites, where the sites have been ruled, in court, to be legal in their native jurisdiction (Spain). Today, we have the proposal in one draft law in the US for the federal government to be able to issue lists of domains which should not resolve and for all US ISPs to blacklist those domains on their resolvers automatically.

The assertion which annoys this troll is that DNSSEC solves these problems. It does not.

A government which can force changes in handling does not need to attack the packets solely at the point in the federation of DNS where a query is issued. Bear in mind that these days, we have NSEC3 minimal covering NSEC [†] doing inline near-wire-speed signing of DNS responses from authoritative servers, so the performance is there. If a government wish to control the DNS for “example.com”, they merely need to issue mandates about the signing keys used for the root zone, and control the root resolvers which the ISPs use, then operate some almost-transparent proxy DNS servers, which claim to be authoritative and pass through most queries and responses.

The governmental agency controlling a given nation's DNS need to issue their own keys for the root zone. They then re-sign the anchor public keys for all the entries within the root, except those for “.com”, for which they issue their own signing key. After that, they transparently re-sign all public keys for domains within .com except for example.com, for which again they issue their own keys.

At this point, replacing the X.509 PKI anchors in DNS with their own certificates is trivial.

Congratulations, by moving to put all certificates in DNS, you've created a single point at which control may be taken and provided the incentive to spend the money on building the farms of servers dedicated to nation-state level DNS serving with signing.

If the attempt is to defend against rogue nation-states which hijack traffic to, eg, cnn.com, then you've just failed and made it even easier for them to do so.

-The Grumpy Troll

EDIT:
[†]: oops, NSEC3 is the fixed version of NSEC which uses pre-computed hashes, chaining the hashes, to avoid disclosure (RFC 5155) and is what folks are moving to; inline signing was RFC 4470 "Minimally Covering NSEC Records and DNSSEC On-line Signing"; sorry for any confusion.

Comments

Phil P
Two things that the example of China shows us are that it's perfectly feasible for a very large nation to decide that they don't care if their citizens know they're being censored, and that you don't need to block everyone, provided that you block by default and can keep _enough_ people in line that those who disagree are marginalised.

Once the framework for control is in place, those whose resolvers use other keys must first have gotten those other keys, which is harder than memorising an IP address; sure, one leak is all it takes, but it's another way to put a dampening effect in place.

I'm not saying DANE is evil or any hokum like that; I am saying that using the efforts of a nation-state actor to justify changing the trust schemes for privacy keys to a system which is still vulnerable to nation-state actors and only protects against random criminals is deeply ironic and not well thought out.

Ultimately, while I think that we'll find better solutions than those currently on the table, too many people are looking for a magic bullet and something which will provide a binary secure-or-not facility for communications. They're completely missing that all security begins with trust and deciding who you trust, how you trust and how you maintain chains of trust. Not everyone trusts the same people, and until we figure out what is the minimum that end-users need to _understand_, at a deep level, about trust and hierarchy in order to protect themselves on the Internet and design simple solutions around that minimal level of understanding, all our attempts at solutions will be tragic failures. And I mean tragic, because in some places people depend upon private secure communications for their lives.
Bill Owens
I suppose that if the censorious government is willing to be so obvious, they could do that - but everyone, within and without, would know that they've usurped the chain of trust. And pushing the keys into ISPs isn't enough, they have to be on every validating resolver - potentially including every desktop. If that's the case, they might as well erase all of the CA cache and replace it with one of their own, from which they can re-issue all of the SSL/TLS certs.

Key to the exploitation of the recent DigiNotar breakin was the fact that in Iran it was used to implement a hidden, quiet MITM attack, without the users' knowledge. At least until someone using a recent version of Chrome noticed the error message, because Chrome implements a Google-specific check that's similar to one of the DANE modes of operation. The presence of that check on the user's computer meant that the national-level MITM was thwarted, because they apparently wanted it to be hidden.

The serious (and highly objectionable) proposals within the US seem to have been made without any knowledge or even awareness of DNSSEC. And although they would potentially act like a MITM attack, they don't intend to transparently replace the affected website and intercept the traffic as was the case in Iran - they want to interrupt access and redirect users. DNSSEC only prevents the redirection part, the interruption still works just fine.
Phil P
Not seeing the problem. A country which wants to censor content makes using their trust anchors in DNS a requirement of running an ISP. Sorry, I skipped that because it seemed so obvious to me.

The choice of trust anchor for the root only helps if it's a free choice and people can use the IANA one (assuming that's the right choice, which it currently is). In countries which censor and hijack content, mandating using a different anchor is trivial.

I mean, even in the USA there are serious proposals (as part of COICA) to use lookaside lists for censoring DNS results in resolvers where the authoritative servers are outside of US jurisdiction. That means mandating configuration of DNS resolvers at ISPs. Once that's done, the framework is in place for ever more controls.
Bill Owens
You wrote:
"The governmental agency controlling a given nation's DNS need to issue their own keys for the root zone. They then re-sign the anchor public keys for all the entries within the root,"

I think you're missing a step there: for this attack to succeed, the agency would need to generate keys; then install those keys in all of the validating resolvers 'downstream', that is, all of the hosts against which they wished to launch a MITM attack; and then re-sign the root zone. Without that step, the replacement root keys would not validate. A difficult task, given that the real root keys are widely published and included in all validating resolver software (for example, in every modern Mac - even though validation isn't enabled by default, the keys are still there).
Categories: x509 DNSSEC TLS pki crypto ssl internet federation