Schneier on Security

Clive Robinson • April 18, 2018 10:53 PM

At best it trys to protect the name requested in one direction only (from client upwards). What it does not protect is thay the client has made a request, nor does it hide any changes that request has made.

Thus as @Argus has noted the system is easy meat for even simple traffic analysis.

There are two issues to consider,

1, Is the existing DNS going to leak information as well.

2, Can the traffic analysis be reduced / eliminated.

The answer to the first is the existing DNS is designed to hemorage information at every stage thus provide a way for the information to be found.

The answer to the second is as @Thoth notes posible for some of the path of the client request.

The problem is that of Tor that I have been mentioning for several years now. As long as the client or the final server are not integrated into the mix network then some level of traffic analysis and leakage will happen.

The message is if we want to make the DNS in anyway private we have to get rid of the existing DNS if we do not the system to leak some information that a sufficiently high level attacker will be able to trick the DNS –because they can subpoena the DNS PubKey pair– from a leak that is a trickle to a full blown torrent.

That is we don’t want to “prune the tree” of the existing DNS we want to “chop it down, and burn every last leaf and twig of it” leaving only the memory of why “efficiency -v- security” is so often a problem as it is with the existing secure DNS setup.

So far so easy, the question is what to replace it with, which will have not just sufficient crypto strength to avoid subversion but sufficient human strength to avoid the MICE / $5 wrench / judicial soloution at the heart of the replacment name service. But also survive the equipment they buy from being “enhanced in transit” by the likes of a SigInt agency. All so the top layer of the domain name distributed data base can actually be trusted, so the next layer down has a trusted foundation etc.

I could go on but people need to understand that the SigInt, IC and LE agencies do not behave as “rational actors” therefore they will go to any lengths to protect their rice bowls. Whilst the SigInt and IC try to remain out of sight the likes of the FBI and DOJ are about “sending messages” to steam roller all opposition. They only came unstuck with Apple because they were to full of themselves and did not do their initial ground work sufficiently.

Thus perhaps the first place to start fixing the DNS is by fixing the sociopath problem in variois government agencies. Which all current “oversight” systems are never going to do. It’s a fundemental issue with all hierarchical systems be they human or otherwise, power / control / corruption are most easily wielded from the top.

So perhaps we should have a think about how to develop a non hierarchical system. Contrary to popular opinion such systems do exist and they can be made secure at a price.

Then we have

Clive Robinson • April 19, 2018 4:13 AM

@ Roggle,

… your threat model involves hardware being interdicted and humans being compelled by tech-stupid courts or $5 wrenches.

Of those three there are known solutions to two of the “interdiction” is something that even the US Department of Defence is still working, especially the “supply chain” part of the problem.

The issues with the judiciary are most easily solved by never having what they desire in their jurisdiction or you having access at any time.

For instance lets say I design an embeded device for you and I make it sufficiently tamper proof. It consists of two parts the home unit and the mobile unit. I generate to sets of PubKey pairs P1pub/P1pri and P2pub/P2pri, I then shred the four primes used to generaye them. I embed P1pri and P2pub in the home device and P1pub and P2pri in the mobile device.

It’s fairly easy to see that the two devices can communicate data secretly across an open network simply by use of the PubKey pairs. Importantly it can be shown that you have know knowledge of the keys and cannot get access to them. Further that if you are caught with the mobile device it is clear that whilst they might be able to read any new messages from the base and might be able to generate new messages from the mobile, there are protocols that can be used to establish ephemaral keys that if they have been used in the past are now lost to the world and unrecoverable. You as the user can be compleatly oblivious to this and other techniques can cause ephemeral key regeneration/renegotiation sufficiently frequently that even if mobile device is grabed powered up it will have failed to negotiate a new ephemaral key and zeroed the last active one. So it can be shown in court that you not only do not know what the secret keys were you never could have.

Further other protocols can be added to say the home unit that a short while after a failure it zeros it’s PubKey stores.

The real issue of course is can you as a human keep up with the level of OpSec you put into the system and the potential loss of communication that might involve.

The only other requirment is that whilst you and the mobile device might start in the same legal jurisdiction, you only use them in different jurisdictions. Thus there is little a judge can do.

Further if you pick your jurisdictions with care there will be no cooperation in a sufficiently timely manner and there are techniques that protect against that as well.

It might sound paranoid but there are plenty of people around following more intense OpSec techniques and they are people just doing their jobs abroad working with valuable information.

Also whilst it might not be of much consolation with such situations the $5wrench does not get the wielder any further than it does the archetypal gaval basher.

It’s a point that certain people have been trying to get through certain political skulls for quite some time and for some reason the lack of “make it so” omnipotence has made the politicos cranky.

But even if they ban such encryption systems or any computer encryption software there are the equivalent of paper and pencil ciphers that are sufficiently secure and phrase codes that can with a little practice be said fairly normally, thus any monitored communications system would be of just as much use to them as a highly enciphered one, which is nil.

As we know from a cranky Australian politition rationality and logic are not things they want stopping their ambitions and plans, hence the rather daft comment about the Laws of Australian being superior to the laws of mathmatics…

Clive Robinson • April 19, 2018 5:13 PM

@ Albert,

It appears to me that applying band-aids to an insecure system won’t make it secure (and may make it worse), so the system needs to be scrapped.

One of the first design errors of the current DNS with regards privacy is that is a “Pull not Push” system. The reason for that choice is that “Pull” is more efficient and timely than Push.

However the implication of Pull is that it has to be not just fast but “low latency” as well, which makes “traffic analysis” way easier… Push however whilst it can work and give low latency information has many needless network issues not least of which is multiple redundant flows of information which whilst it does not reveal user request time refrences does cause a lot of redundant traffic. As with cross-bar switch positioning, access to any DNS information can be efficiently split into multiple “data nodes” around a distributed network.

Clive Robinson • April 20, 2018 7:15 PM

@ Albert,

Any recommendations for an unbound local resolver for Linux?

It’s already there as historically, the way you want to do things, was the way it was originally built to work.

Have a look at your local hosts file[1] all *nix and as MS nicked BSD networking all networkable MS OS’s and for the same reasons Mac OS’s have them.

You also as part of DNS have a local cache on the host machine which in essence is a speed up mechanism as well as to reduce DNS requests.

Simply when you make a network request the OS goes through the file and cache first looking for a match on the domain name. If found the local copy is used unless it is deemed to have gone stale, it’s only then a DNS request across the network is made.

So far so easy…

To do things “automagically” you need to get access to the local DNS client resolver cache. On MS OS’s it’s usually quite simple using “ipconfig”… *nix however is a very different kettle of fish.

On many versions of *nix trying to find let alone read and get into a meaningfull format the cache content is at best an uphill struggle… the reason appears to be in part historical.

If you have ever had to deal with BIND you will probably “have a chill in yer waters around now” it is probably the most used least understood and best avoided piece of DNS resolver software on the face of the planet. Books used to be written about it and strange attractor forces produced black holes in admins otherwise enlightened minds…

The result of that and the usual *nix philosophy of “the programer knows what they are doing” came to the fore. Thus it was left to the application programmer to cache DNS records, and that a request to the resolver would be to get a fresh copy from the wider network… Thus *nix DNS udp traffic can be quite high as most application programmers don’t actually know what they are doing so make assumptions and take simple routes.

Why there is a lack of local resolver cache I have no idea, that’s just the way the developers seem to be happy with. Which is why many distros are like that, there have been a few changes to getting an internal DNS resolver cache.

Once you do get at the cache –if you have one– you next have to get the contents in a meaningfull format. Once you have done that it should not be too difficult to make updates from the cach to the file with a shell script or perl program. But you will need to implement your own “stale” function to prevent the file filling with malvertising links etc.

[1] https://en.m.wikipedia.org/wiki/Hosts_(file)