[Cryptography] Sonic.net implements DNSSEC, performs MITM against customers. Are they legally liable?
phill at hallambaker.com
Sat Oct 11 10:43:12 EDT 2014
On Sat, Oct 11, 2014 at 4:24 AM, Peter Gutmann
<pgut001 at cs.auckland.ac.nz> wrote:
> Bear <bear at sonic.net> writes:
>>Sonic implemented and deployed DNSSEC - and put it on their shiny new servers
>>along with an 'RBZ service' that censors supposed malware and phishing sites.
>>And while they told their customers about DNSSEC, they didn't mention the
> So just to make sure I'm getting this right, Sonic are sending out DNSSEC-
> authenticated but invalid/spoofed/however you want to label them DNS
> responses? As you say, the very thing that DNSSEC was designed to prevent?
It isn't clear but what they appear to be doing is turning on DNSSEC
validation in the resolver, then editing the results.
This is something I predicted long ago and the problem is that the DNS
architecture as received is stupid. DNS is a trusted service so you
should only use a trustworthy DNS service. DNSSEC only ensures that
you do not receive bogus responses. It does not ensure that you
receive a response.
The original idea of DNSSEC was to use the DNS as a distribution point
for keys for use in IPSEC and SSL like protocols. Then it was co-opted
as a mechanism for making the resolver untrusted which was stupid. Its
the tin-foil hat version of crypto-autarky where you use crypto to
eliminate reliance on any party at all, except of course for the ones
you don't notice like ICANN (a US QANGO) or the resolver.
Yes, the DNS resolver can MITM you. Which is why the communications
between the resolver and the client must be encrypted and
authenticated so that you can be suer that you get the DNS service
from the service you chose and not a service that your ISP chose.
I have this machine set up to connect to the Google public DNS. But a
few weeks ago I was seeing Verizon sitefinder inserts. The bastards
had MITM the NXTDOMAIN responses.
So I wrote this spec and have some running code
The first step is to choose your DNS service or set up one of your
own. The client binds to the service using a TLS secured key exchange
that spits out a Kerberos ticket type object. And then DNS
transactions with the service are encrypted and authenticated in both
directions using the ticket.
The design is stateless on the server side and should not impact
performance at all for modern machines. The crypto overhead is
Now for the mind bending part, you probably don't want the
authoritative DNS responses unless they are DANE records or otherwise
contain a key. If it is an A record or a AAAA record you might well
want the resolver to have the ability to modify it.
One reason is to block access to known bots. Just because the Russian
Business Network has bought a domain does not mean that I want my
machine to resolve it. And I have lists of a million bots. I don't
want my machines connecting to them either.
If the policy is chosen by the end user then this is anti-virus for
the Internet. If it is imposed by the carrier or government it is
One particularly fun approach is using it for IPv6 to IPv4 gateways.
This allows a machine that is pure IPv6 with no IPv4 whatsoever to
survive on the transitional Internet without a performance drag.
When the IPv6 client attempts to connect to a resource that is IPv4
only, it returns an IPv6 address at the best available IPv6-4 gateway.
This might be a local gateway or a gateway closer to the desired end
More information about the cryptography