Subject: Securing DNS Re: IAB statement on the RPKI.

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 17 Feb 2010 11:01:38 -0500

One mechanism that was unfortunately pushed asside as a result of the
fixation on end to end DNSSEC would be to for the resolver to use
DNSSEC (and other methods) to authenticate the data it receives and to
use some modification of TSIG to authenticate the communication
between client and resolver.

This model does not make much sense if you stick to the model where
hosts pick up their DNS service from the local host. But it makes a
great deal of sense when you are using a service like Google's DNS. It
would not take a great deal of effort to graft a Kerberos like scheme
on to effect key exchange.

The real problem with DNSSEC is that it has taken so long that the
Internet has changed since. And rather than go back and redesign we
are always told that so much time and effort has been spent already
that we cannot possibly take any time to look at the issues that might
prevent deployment or use. And so instead of the opt-in fix taking six
months as it should have done it took six years and instead of the
zone walking/privacy issue taking six months it took four years.

I am thinking of retitling my RSA talk '2010 The Year of DNSSEC'.

I am not trying to beat up people and say do it the way we did it.
What I am trying to say here is DON'T REPEAT OUR MISTAKES. Look at the
solution that we were forced to adopt when the single rooted hierarchy
proved undeployable.

On Wed, Feb 17, 2010 at 10:01 AM, Basil Dolmatov <[email-masked]> wrote:
> Masataka Ohta пишет:
>>
>> But, the most serious defect of DNSSEC, or PKI in general, is that,
>> despite a lot of hypes, it is not cryptographically secure.
>> Social attacks on trusted third parties makes the parties
>> untrustworthy, which means PKI is merely socially or weakly
>> secure.
>>
>>
>
> There are a lot of deficiencies in PKI, but at present time I can see no
> alternative for establishing trust in loosely connected and large systems.
> If there is one, please advise.
>>
>> For security of interdomain routing, social security of trust
>> relationship between ISPs is just enough to which additional
>> social security by PKI is not helpful.
>>
>
> There are no trust relationships between my ISP and your ISP.
> How my ISP can trust routing announce, which I have got over the network and
> which has your ISP mentioned as the origin?
>
>> For security of DNS, social security of trust relationship between
>> ISPs and between zones are just enough to which additional social
>> security by PKI is not helpful.
>>
>>
>
> Same question applies to DNS. My resolver have no trust relationships with
> your server.
> How I can trust DNS-answer which I have got over the network?
>
> Unfortunately, Internet 20 years ago and Internet today are two
> significantly different networks.
>
> 20 years ago I trusted to nearly all network participants and undoubtedly
> trusted to all network administrators.
>
> Now, the necessity to build the chains of trust is obvious, otherwise you
> will lose a lot. The methods, which are being implemented are definitely not
> ideal (I knew a lot of flaws and weaknesses in systems, which are using
> PKI), but at the same time I do not know anything better.
>
>
> dol@
>
>
>
>>                                                Masataka Ohta
>>
>>
>>
>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/

---

From: Tony Finch <[email-masked]>
Date: Wed, 17 Feb 2010 18:48:37 +0000

> between client and resolver.

I don't think that has been pushed aside. There's not much interest in it
at the moment because the focus is on authoritative-to-recursive DNSSEC.
Maybe attention will turn to recursive-to-stub security once there is more
assurance that the recursive server's answers are authentic.

> It would not take a great deal of effort to graft a Kerberos like scheme

Or use SIG(0).

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

---

From: Shumon Huque <[email-masked]>
Date: Wed, 17 Feb 2010 16:06:02 -0500

> assurance that the recursive server's answers are authentic.

There is also the camp that thinks that stubs should do validation
themselves.

> > on to effect key exchange.

Yeah, I kinda like SIG(0) myself.

If you want to use Kerberos for symmetric key management, there
is GSS-TSIG. But there is a bootstrapping problem -- Kerberos
clients commonly use DNS SRV records to locate Kerberos servers.

Most stub resolvers can't do any of this today (HMAC-MD5/SHAxxx 
TSIG, GSS-TSIG, SIG(0), etc) as far as I can tell.

--Shumon.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 17 Feb 2010 19:14:43 -0500

> between client and resolver.

Whatever made you think that had been "pushed aside"?  And it seems to
me SIG(0) will work better.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 17 Feb 2010 14:44:45 -0500

Recursive to stub is the piece where you need to have Apple and
Microsoft provide platform integration. And they have the longest lead
times. So that is the piece that you need to prioritize.

If we move to a mode where most people have transitioned from ISP
provided recursive DNS to some form of managed recursive DNS service,
the managers of those services may employ other strategies to provide
a significant improvement in DNS security even without DNSSEC
adoption.

One of the big fallacies of DNSSEC is the idea that providing clients
access to the unfiltered authoritative DNS source is the same as
securing the DNS. That was the case when DNSSEC was designed, today
most endpoints would prefer to opt to connect to some sort of filtered
DNS with malware and crimeware sites removed.

The biggest DNS security vulnerability is in the information that is
input to the DNS publication service. Most hijacking schemes have been
due to attacks on registrars.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 18 Feb 2010 18:53:01 -0500 (EST)

> DNS with malware and crimeware sites removed.

"most"? That's quite the claim. If so, then opendns and friends would be
much busier rewriting our DNS packets.

> due to attacks on registrars.

I thought the most used hijacking schemes used dancing hamsters or nude Britney
Spears promises to install a new version of SYSTEM32\etc\hosts. In fact, it was
so bad that Microsoft even hardcoded their own update servers IP's in their
own DLL's.

I have only heard of 2 or 3 attacks via registrar accounts. I've heard of many
more compromised caches and hosts files.

But I look forward to your substantiation that "most" of us prefer our DNS to
be rewritten for security and saving us from typos by redirecting us to
advertisement servers (malicious or not)

Paul

---

From: Paul Wouters <[email-masked]>
Date: Thu, 18 Feb 2010 19:41:02 -0500 (EST)

On Thu, 18 Feb 2010, Phillip Hallam-Baker wrote:

> The point is not to protect the DNS. The point is to protect the
> people. And that means that maybe you don't want your machine to
> resolve every domain name.

That sounds very much like the tapping/crypto debate. "You may not
secure your communications because we're using its weaknesses for your
protection".

Not securing DNS because some people are using it for something completely
different, namely a filtering service, is not an acceptable solution.

But besides that, services like opendns can still fetch and validate DNS,
and then continue strip it and rewrite it for those endusers that prefer
such a service. DNSSEC does not change that at all.

Paul

---

From: Mark Andrews <[email-masked]>
Date: Fri, 19 Feb 2010 12:10:03 +1100

> such a service. DNSSEC does not change that at all.

DNSSEC can even be used to secure reputation data to allow different
applications on the same box to make different decisions about
whether or not to trust the data returned from the DNS even if it
is signed using DNSSEC or not.

One could also use  EDNS options to tell the recursive resolver
whether to filter or not a particular query or to pass back a
recommendations to filter the response.  The data itself would still
be signed and verifiable.  The recommendation itself can be secured
with TSIG/SIG(0).

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Thu, 18 Feb 2010 20:59:59 -0500 (EST)

On Thu, 18 Feb 2010, Phillip Hallam-Baker wrote:

> The key point is choice. Just as some people CHOOSE to install
> products such as Norton Anti-Virus that stop certain applications
> running on their machine, the typical Internet user should probably
> CHOOSE to use a DNS service that has the known crimeware sites
> eliminated.

Should they also CHOOSE for a porn filter. And a filter on politically
sensitive words? Where does our job end to let the user CHOOSE their
censorship? And again, you make it sound like DNSSEC is taking away that
choice, which is clearly not the case.

> The point is that the particular obsession with 'end to end' solutions
> means that we loose the ability to deploy architectures that provide
> greater protection against the attacks that actually matter.

It prevents hacking the protocol (for good AND for evil). And that is
a good thing.

> DNS hijacking is a very rare type of attack.

No it is not. It depends on your environment. I'll grant you that its
more likely you'll end up on a phising side then caught in a DNS spoof,
but that does not validate your opinion of not rolling out stronger
security just so people can play games with protocols.

And as Mark showed, there are legitimate ways of piggypacking filtering
services with DNS using EDNS options.

> Securing the mapping of
> DNS names to IP addresses will not provide a major reduction in
> expected losses due to attacks.

It will greatly improve security by providing a hierarchical distributed
signed database. You will see many new applications leveling this new option.

> We already have domain validated SSL
> certificates that meet that need quite adequately.

You haven't been around in the last year? When we had SSL attack after SSL
attack? A 2 second email verification for a "valid for the entire world"
certificate is not what I would call "quite adequately".

> The value in DNSSEC lies in being able to establish a coherent network
> based system of security policy distribution.

Sorry, I am not sure what this means. But if it is another application of
distributed signed data, then yes, it is another case for the adoption of
DNSSEC, not for critisism that it would block some filtering technique,
which it doesn't)

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 18 Feb 2010 19:12:46 -0500

The typical attack these days is to direct a user to a malware site.
This is usually spam but can easily be a malicious redirect or inline
on a hacked Web site.

Once the user is on the malware site they are either asked to install
the malware or the site does a driveby download on them.

Other sites we would like to avoid visiting are identified phishing sites.

Sending the malware through email pretty much fails these days as very
few email services will deliver executable attachments. Thus the need
for the malware site approach.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 18 Feb 2010 20:24:26 -0500

more ad hominem and irrelevant comparisons.

DNS hijacking is a very rare type of attack. Securing the mapping of
DNS names to IP addresses will not provide a major reduction in
expected losses due to attacks. We already have domain validated SSL
certificates that meet that need quite adequately.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 19 Feb 2010 08:17:42 -0500

If people want to prevent their TCP/IP enabled lightswitches from
viewing porn as well as stopping them from accessing malware sites,
then I guess they could use this mechanism.

I do not consider stopping my computer from accessing malware or
crimeware sites to be 'censorship'. Censorship is what people do to
other people. I have never heard of a anti-porn crusader who says that
they need to be protected from porn, they always worry about what it
would do to other people.

The fact that the DNS can be used as a censorship point only
reinforces the need for the endpoint to be more careful in their
choice of resolution service. The current DNS model was conceived when
a VAX 11/780 only just fit in a standard elevator and cell phones were
considered futuristic spy gadgets. Had the need for endpoints to move
about been considered I don't think the default of taking DNS
resolution service from your local network provider would have been
acceptable.

For a whole host of reasons it is a really bad idea for ICANN or any
other single point authority to be in the business of filtering domain
name issue. Since it is also a bad idea to route packets to names
controlled by the Russian Business Network it follows that most end
points should not be using the authoritative DNS name space.

Given that the vast majority of medium to large sized businesses seem
to already have some form of restriction on Internet access, I don't
see that trying to enforce this by making the DNSSEC protocol issue
failure reports is going to change anything. If the technical measures
were effective then the businesses would simply turn off DNSSEC. But
it is rather more likely that they won't work at all because nobody
has yet worked out what a Web browser should do if it is told that the
site exists but the resolution of the DNS request is blocked. Perhaps
they could send a request for the missing packets by carrier pigeon.

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 20 Feb 2010 04:23:37 +0900

> greater protection against the attacks that actually matter.

FYI, there is no point to insist on 'end to end' here, because DNS,
including plain old one not necessarilly DNSSEC, is not end to end.

DNS servers are intermediate intelligent entities betweeen peers,
though the servers are operated zone administrators between peers,
which are, in general, not ISPs between peers.

The lack of end to end property makes DNS, including DNSSEC,
vulnerable to MitM attacks at intermediate zones.

Though DNS resolvers can be, to avoid cache poisoning, implemented
end to end between client hosts and DNS servers without intermediate
resolvers, it's end to end merely between the client hosts and the
DNS servers and not between the clients and application servers of
the clients.

						Masataka Ohta