SoylentNews is people
SoylentNews
The Domain Name System (DNS) is a plain-text service that lets anyone who can see “the wire” capture a user's DNS traffic and work out whether they're asking for naughty.com or nice.com. So to help enhance its privacy a group of researchers has proposed a more "Oblivious DNS” protocol.
However, as the group explained here, even encrypted DNS (for example, DNS over TLS) is still exposed at the recursive resolver (that is, the DNS component most directly connected to the client), because that server decrypts the user request so it can fetch the IP address of the site the user wants.
In other words, whether you use your ISP's resolver, or one provided by a third party like Google or Cloudflare, at some point you have to trust the resolver with your DNS requests.
[...] To get around this, Oblivious DNS is designed to operate without any change to the existing DNS. As its designers write, it “allows current DNS servers to remain unchanged and increases privacy for data in motion and at rest”.
Instead it introduces two infrastructure components that would be deployed alongside current systems: a resolver “stub” between the recursive resolver and the client; and a new authoritative name server, .odns at the same level in the hierarchy as the root and TLD servers (see image).
In this model:
- The stub server accepts the user query ("what's the IP address of foo.com?"), and encrypts it with a session key/public key combination;
- The recursive name server receives the request (with .odns appended) and the session key, both encrypted;
- The .odns tells the resolver to pass the request up to the ODNS authoritative server, which decrypts the request and acts as a recursive resolver (that is, it passes requests up the DNS hierarchy in the normal fashion);
- The ODNS encrypts the response and passes it back down to the stub, which sends the response to the client.
The authors explained that this decouples the user's identity from their request.
The recursive resolver a user connects to knows the IP address of the user, but not the query; while the ODNS resolver can see the query, but only knows the address of the recursive resolver the user connects to, not the user.
Similarly, an attacker with access to a name server never sees the user's IP address, because the request is coming from the ODNS server.
The group has posted a conference presentation from late March here [PDF], and emphasises that Oblivious DNS is a “work in progress”.
(Score: 3, Insightful) by insanumingenium on Wednesday April 11 2018, @04:20PM (8 children)
This article was terribly written. If an attacker has access to your MAC Address, they are on your same network, and would have it regardless. If they are on the same network, they are between you and your stub server (as drawn) and they have the pre encrypted requests.
They mention having your subnet, which is just imprecise to incorrect no matter how you slice it. They would have your IP, not subnet, and while the IP is the actual identifying information, you can't define a subnet without a mask which definitely isn't provided.
If you are trying to pitch a security concept, you need to address pedantic concerns like this because they make you look like an idiot.
Setting up a stub is going to be beyond most users, and unless that stub is local (preferably integrated to the client itself) it is a total failure.
If your stub resolver needs public keys to encrypt the request, you can't load balance those requests unless your share that same private key everywhere you may need to resolve.
This difficulty in distributing infrastructure sounds to me like a great way to aggregate "sensitive" requests in one place, and require only a single key to get all they keys to the kingdom.
Correlation attacks will be trouble, even if you assume there will be a huge flow of requests, correlation is powerful, especially given a large enough data set. Speaking of historical data, forward secrecy isn't optional in this day of national security letters.
(Score: 2, Informative) by Anonymous Coward on Wednesday April 11 2018, @05:33PM (1 child)
I think some what related to your post.
edns-client-subnet
https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-subnet-08 [ietf.org]
https://datatracker.ietf.org/doc/draft-vandergaast-edns-client-subnet/ [ietf.org]
https://tools.ietf.org/html/draft-vandergaast-edns-client-subnet-02 [ietf.org]
https://datatracker.ietf.org/doc/rfc7871/ [ietf.org]
(Score: 2) by insanumingenium on Wednesday April 11 2018, @07:52PM
Thanks for the link, I did not know about that DNS option. I wonder if it gets much use...
(Score: 0) by Anonymous Coward on Wednesday April 11 2018, @05:53PM
the register's tech writers are hilarious. they are constantly spewing nonsense about various Linoxes too.
(Score: 2) by frojack on Wednesday April 11 2018, @06:56PM (2 children)
Most of these issues are resolved by moving your stub server closer and closer to your client. Perhaps eventually right into the client. Further there's no reason you can't have stacked stubs.
No, you are mistaken. I've always had this sig.
(Score: 2) by nobu_the_bard on Wednesday April 11 2018, @07:36PM
If the stub is in the client itself, isn't identifying the stub as good as identifying the client?
(Score: 2) by insanumingenium on Wednesday April 11 2018, @08:08PM
I would call that a minimum barrier for security, but I don't think that saying they will be integrated in clients resolves more than the most trivial of issues.
Can you imagine trying to get that set up? Which is worse, walking an end user through entering in their DNS public keys, or training them to trust whatever gets assigned (here comes a new DHCP option) as legitimate.
Not sure what you mean by stacked subs.
(Score: 2, Interesting) by dwilson on Wednesday April 11 2018, @08:34PM (1 child)
I disagree with a lot of what you said.
My network consists of the machines running in my home, connected to my (openwrt-running) router, which is connected to the wider internet via an adsl connection to my local isp. I'm not worried about attackers on my local network. I imagine the vast majority of people are in the same boat.
Perfect is the enemy of good. If this solution helps mitigate anyone outside my network knowing my dns requests, that's a Good Thing. Address the edge cases as they come up, don't wait for a perfect solution for everybody. Sure, that's biased towards my needs and my setup. What other metric would I use. realistically?
That sounds like a valid concern.
- D
(Score: 2) by insanumingenium on Wednesday April 11 2018, @09:46PM
The placement of the stub, they don't explicitly define, and this isn't a matter of edge cases, if the stub is placed on an untrusted network, this proposal provides less than zero benefit. At least without it you are potentially aware you are totally unprotected.
The first half of my previous response was not a technical critique, but a complaint that their writing was unclear bordering on deceptive. To be clear, I also didn't explicitly state that I wasn't referring to The Register's story (which I didn't read when an academic link was available) but to the linked source [princeton.edu] and sublinked slideshow [princeton.edu]. Admittedly, someone else already pointed out there is an extension to add subnet information to DNS requests which I was unaware of, but I can't imagine the same is true of the MACs. Even given the subnet extension I am not clear on how this proposal would interact. Do these guys at Princeton not have any professors acting as advisors to point out that their summary sucks? Am I wrong to expect clarity from academic publications?
I normally will be the first person shouting that perfect is the enemy of good with you, but if you can't write a coherent proposal, how is anyone supposed to support it?
Security has to be well thought out, suggesting a vulnerability that doesn't exist absolutely discredits these authors. My comment wasn't that this isn't viable (though to be honest I don't see it being so at scale), but that making a security proposal that is unclear is a terrible mistake. I would personally demand anything dealing with security to be defined totally and transparently, I have seen too many implementations of well defined standards get details slightly different in ways that put people at risk.