Subject: Defining defense levels...

From: Nicholas Weaver <[email-masked]>
Date: Fri, 22 Aug 2008 09:25:37 -0700

One thought (again, I don't know how much this has been hashed out) is  
how robust do DNS resolvers REALLY need to be?

Any comments on the following?

I personally believe that resolvers should be robust to anything short  
of a man-in-the-middle ("Aware & Blocking"), yet man-in-the-middle is  
almost irrelevant for purposes of defending DNS.  [1]  Thus as long as  
the DNS resolvers are strong to anything short of the man-in-the- 
middle, its good in practice.

At the same time, such robustness must ONLY involve changes to the  
resolvers: the resolvers should be able to protect themselves, without  
relying on the authoritative servers making changes (although  
authoritative servers may suffer more load, especially servers which  
return some out-of-standard nonsenses.). [2]

And probabilistic protection is perfectly good.  We don't need perfect  
protection against blind attacks, we just need to ensure that the  
attacker resources involved are far better spent elsewhere.

My thoughts:

Against blind attacks, I believe the following principles should apply:

a)  No birthday attacks, of course.

b)  >=20b of entropy for purposes of protecting the transaction [3]

c)  >=40b of entropy for purposes of protecting the cache [4]

d)  Detecting when network entropy (port #) is reduced or eliminated  
by an in-path network device, allowing the resolver to accurately  
estimate the entropy it is generating in the requests.

e)  Detect and respond when there is .001% of a chance that a blind  
attack created one or more corrupt cache entries by either  
revalidating or voiding the cache.

f)  NO "race until win" scenarios for ANY given mapping in the cache.   
ALL blind attacks should be either "Race once per TTL" or "Race until  
another race until win".  Blind attacks should always cost time as  
well a packets.  [5]

ALL of the previous principles seem doable using existing techniques  
(port and 0x20 randomization, duplication, a single global counter to  
count unsolicited replies, and some seemingly simple data acceptance  
policies)

Against transparent attacks, I believe the following should apply:

If a resolver, within its normal transaction timeout, receives a  
second reply with a differing value but which would have been  
otherwise accepted (matching on TXID, port, server, 0x20, etc), this  
must be considered an attack on both the transaction and the cache. [6]

If the resolver is an intermediary, it MUST forward the second  
response back to the original requester, with the TTL for the "new"  
value set to 1 second.

For the resolver's cache, any entry which MAY have been potentially  
affected by the second reply MUST be treated as corrupted by an  
attack.  Thus, depending on how much information is recorded and  
available, various cache entries may need to be voided or undone (up  
to all cache entries for the domain in question, if more precise  
record keeping is unavailable).  Even if this would not be considered  
an attack, it doesn't actually make sense to cache anything which may  
have been dependent on this response.

For the final client, it is up to the client to determine what to do,  
but the strong suggestion is to consider this an attack and abort any  
transaction involving this name.

However, if the end client does not treat this as an attack and abort  
subsequent TCP connections to the final IP, this loss of transaction  
protection means that the few authorities which trigger this alert  
through "normal" behavior will simply see their results not cached  
rather than not accepted by the client.

[1] If an attacker can man-in-the-middle the naming stream of a  
victim, he can probably man-in-the-middle the data stream.  If the end  
protocol desired is weak to a man-in-the-middle, reliable naming does  
no good.  If the end protocol is robust to a man-in-the-middle, it  
never really trusted the DNS record.

[2] This is why I'm not a believer in DNSSEC.  It has both bad network  
effects (both the resolver and authority needs to change behavior, yet  
the changed behavior only protects the intersection of the two sets,  
so neither resolvers nor authorities have strong internal incentives  
to deploy), yet does not actually provide, to my mind, all that much  
meaningful system security because the other options available to a  
man-in-the-middle in practice.

[3] Blind transaction attacks, when combined with protections that  
provide "race once per TTL per name", as far as I can tell, only work  
against some seriously broken protocols.  By specifying a different  
level of protection for transactions and the cache, this allows  
duplication to protect the cache while still successfully resolving  
(but NOT caching) sites which return different values on back-to-back  
queries when duplication is needed to meet the entropy budget.

[4] Anyone who wants to launch a TB DOS to poison my cache has better  
things to do.

[5] I believe that the proper policy on accepting data into the cache  
can provide this, combined with treating a failure to lookup a name as  
an event with a ~30 second TTL.  This property is an important  
COMPLEMENT to increased entropy, not a substitute.  "Race until win"  
does not reduce the number of packets an attacker requires, only the  
time period.

[6] This will occur with high probability whenever there is a blind  
attack that doesn't also block the authoritative server or create  
traffic with a DOS condition.  It will ALSO occur with high  
probability if an attacker is able to directly observe the request to  
craft a reply, but is not fully in path.  More importantly, a  
preliminary survey survey suggests that only a few authorities  
actually do return such nonsense.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Aug 2008 11:23:22 -0700

> attacker resources involved are far better spent elsewhere.

This isn't strictly true, because there are on-path non-cache- 
poisoning attacks to DNS that are not MitM attacks but that let me  
reliably MitM your HTTP connections.   And these attacks are easily  
prevented with DNSSEC, and completely unpreventable with, e.g., port  
randomization.

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 22 Aug 2008 11:37:06 -0700

> prevented with DNSSEC, and completely unpreventable with, e.g., port  

Those are "Aware" attackers, NOT blind attackers in the taxonomy I'm  
pushing, as they know the entropy of the request.

See http://www.ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01459.html 
  for the taxonomy I'm using.

For such an attacker, the question is, are they "Transparent" or  
"Blocking": able to squelch the legitimate reply?

An Aware, Blocking attacker IS almost certainly a man in the middle  
(or a packet snoop who's also DOSing the authority with enough traffic  
that the requests fail, who you might as well call a MitM).

Such an attacker can just as easily directly MITM your TCP stream in  
almost all cases, because the path for the naming is almost certainly  
the path for the data.

An Aware, Transparent attacker (eg, a typical packet injector) you CAN  
detect by looking for mismatched responses: where you get two  
responses to the same query but with different values.  You can also  
MITIGATE such attack's damage to the cache, and NOTIFY the end client.

We used such a technique very successfully to detect injected TCP  
Reset packets, and if applied to DNS, the number of authoritative  
servers which return two responses to the same query but with  
different answers is VERY low.

And if the client is suitably paranoid, can treat as an attack in  
progress.

The probability of detecting being just the probability that the  
legitimate response is returned by the authoritative server.

This is why I try to be precise about taxonomy.

Or is there some form of attacker who's not blind but doesn't know the  
entropy of the request?

What holes are there in the following two axes of taxonomy:

Blind vs Aware:  Does the attacker have to guess or does he know the  
entropy of the request?

Transparent vs Blocking: Is the legitimate response processed and  
returned by the legitimate authority, or is the attacker able to block  
the legitimate request processing?

And which attackers are "Aware" (see the packets, assuming a good  
server), "Blocking" (able to block the request) other than either a  
full man-in-the-middle on your DNS flows or someone snooping packets  
on your DNS flows who's also creating/taking advantage of a DOS  
situation?

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Aug 2008 11:53:06 -0700

> MITIGATE such attack's damage to the cache, and NOTIFY the end client.

This only works if the attacker follows the rules.   If the attacker  
jams the 802.11g network during the time when the response is  
expected, you'll see a short stutter in the network, and probably not  
notice it.   And since the jamming happened at the link layer, it will  
just look to the resolver like no packets arrived except the  
attacker's packets.

I suspect that producing a jammer that could be finely controlled in  
this way would be about a day's work for a knowledgeable  
practitioner.   My point being that this is not at all an expensive  
attack.   It's something I could do on the IETF meeting network and  
probably completely escape notice.

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 22 Aug 2008 12:08:27 -0700

On Aug 22, 2008, at 11:53 AM, Ted Lemon wrote:

> expected, you'll see a short stutter in the network, and probably  
> not notice it.   And since the jamming happened at the link layer,  
> it will just look to the resolver like no packets arrived except the  
> attacker's packets.
>

However, such a jammer can JUST AS EASILY be a MITM on the TCP stream  
itself!

Thats my point.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Aug 2008 12:14:05 -0700

> However, such a jammer can JUST AS EASILY be a MITM on the TCP stream

No, in order to do this you'd have to jam continuously, which would be  
noticed.

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 22 Aug 2008 12:20:09 -0700

On Aug 22, 2008, at 12:14 PM, Ted Lemon wrote:

> No, in order to do this you'd have to jam continuously, which would  
> be noticed.
>

Not really.

A:  End hosts don't notice currently: airpwn and Cookie Monster work  
just fine today.  Write your own in Click, its easy!

B:  With the low latency of the local LAN vs remote behavior, I can  
launch the nice airpwning completely by the time the legit SYN gets  
back.

C:  I could just ARP cache poison you and MITM that way...

D:  I could DHCP poison you when you first connect and MITM that way...

etc etc etc.

Against an adversary on the local wireless network, you have to assume  
either full end-to-end crypto on the final application or you are  
sunk.  Period

In such a threat model, DNSSEC buys almost nothing.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Aug 2008 12:40:34 -0700

> either full end-to-end crypto on the final application or you are

Opportunites to jam DHCP are infrequent.  Jamming an entire TCP stream  
is hard, and you only have to miss once to get caught.   Jamming  
single DNS transactions is easy, and opportunities to do will be  
frequent.  If you miss, you don't get caught - the traffic just goes  
through.

What's nice about DNSSEC is that there's no user in the loop.   To jam  
DNSSEC, you have to actually break the protocol - you can't just  
convince the user not to use it.   It's true that SSL will protect you  
if you use it correctly, but whether or not you use correctly it  
depends on the user.

I think you're seriously discounting the importance of human factors  
when you say that the security of the DNS channel doesn't matter.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 22 Aug 2008 13:16:04 -0700

At Fri, 22 Aug 2008 12:40:34 -0700,
Ted Lemon wrote:
At Fri, 22 Aug 2008 12:40:34 -0700,
> when you say that the security of the DNS channel doesn't matter.

Without getting into some sort of huge SSL vs. DNSSEC debate, I'd 
be interested in hearing what you think "using it correctly" 
consists of. 

Do you mean that the SSL implementations allow the user to override
things that look like security errors to the stack. If so, the stack
could, of course, refuse to let you do anything it thought was unsafe
(indeed, some older browsers did this) but experience indicates that
users find this intolerable. If your argument is that DNSSEC is better
because you don't get an opportunity to override the stack, I think
there's some room for debate about whether that's really an improvement.

-Ekr

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 22 Aug 2008 13:33:53 -0700

On Aug 22, 2008, at 12:40 PM, Ted Lemon wrote:

> Opportunites to jam DHCP are infrequent.  Jamming an entire TCP  
> stream is hard, and you only have to miss once to get caught.    
> Jamming single DNS transactions is easy, and opportunities to do  
> will be frequent.  If you miss, you don't get caught - the traffic  
> just goes through.

Actually, its easy.  You force the user to dissassociate and  
reassociate, there are attacks for that.  Voila.  Access point, DHCP,  
ARP, take your pick.  You can spoof em all.

And for most TCP attacks, you don't actually need to jam because the  
recipients aren't looking for mismatches.  Spoof the SYN/ACK, chat  
away, and be happy.  It works like a charm!  Every time.

As a bonus, since apart from the real SYN/ACK (which you CAN jam using  
your method), most remote systems won't actually send RST packets to  
these "unsolicited" data packets it sees, and even if they do, as long  
as you keep the data flowing, any RST will be out of sequence and  
ignored on the recipient.

So you CAN actually MITM TCP, WITH a jamming property, against most  
systems in practice on the wireless network, because most won't send  
the RSTs that the packets say in the first place these days, so all  
you need to jam is the SYN/ACK

> What's nice about DNSSEC is that there's no user in the loop.   To  
> jam DNSSEC, you have to actually break the protocol - you can't just  
> convince the user not to use it.   It's true that SSL will protect  
> you if you use it correctly, but whether or not you use correctly it  
> depends on the user.

But, see the above, even with the fully secured NAME->IP mapping, you  
are still in the exact same position in your attack scenario:  
completely h0zed unless the user's actual protocol supports end-to-end  
crypto right.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Aug 2008 14:36:37 -0700

> completely h0zed unless the user's actual protocol supports end-to-end

On reflection, I think that I am arguing about the wrong thing.    
You're right that DNSSEC doesn't stop a MitM attack.   A smart  
attacker would allow DNS to flow freely, and attack elsewhere, if they  
controlled your link to the rest of the world.   To protect against  
this would require much more careful use of SSL than is common at  
present, and DNSSEC would not help.

However, there's a case that you haven't really covered in your  
analysis.   That's the case where the attacker gains control of the  
local cache.   They don't have control of the path, but because they  
control the cache, they can convince you to send packets to them  
instead of to the correct destination.   Your detection heuristics  
would completely fail here, because there's no competition between a  
blind or transparent attacker and the cache - the attacker *is* the  
cache.

Also, you propose is that we just assume the answer we receive is  
correct, and abort the transaction if it turns out not to be.   But  
the security handshake is probably finished at this point, and the  
private data has been leaked to the attacker.   And we don't *know*  
that the data has leaked - we just think it has.   So we're  
potentially going to be exposing the user to false positives that will  
train them to click through whatever warnings we might present.

You could kludge around this a bit by choosing a wait time shorter  
than the maximum timeout, and not starting the transaction before  
that.   But to get any degree of reliability, I think you'd have to  
introduce unacceptable delays.

Also, you assume that the application designers will get it right.    
My app has to have a way of receiving an out-of-band notification from  
the resolver to tell me to abort the transaction, and I have to abort  
the transaction in a way that is appropriate to the circumstances, up  
to and including telling the user they need to change their password  
pronto.

In the case of a web app, the engine that would have to make this  
decision (the browser) doesn't really even know the security model of  
the web app, so it's really not going to be able to give appropriate  
advice to the user.   This window of opportunity introduces a degree  
of complexity to trusted apps that I think is unlikely to work in  
practice, even if it could work in theory.

By contrast, if we validate the DNS response before we use it, we  
close off these windows of opportunity completely.   We certainly do  
not eliminate all avenues of attack, but we do eliminate this one.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 25 Aug 2008 21:48:47 +0900

Ted Lemon wrote:

> DNSSEC, you have to actually break the protocol

No. It is enough to break a zone in the loop.

> It's true that SSL will protect you  

Security of SSL, DNS or PKI in general depends both on the user and
intermediate administrators.

> when you say that the security of the DNS channel doesn't matter.

You're seriously discounting the importance of human factors  
when you say that the security of the DNS channels through zones
don't matter.

PKI, including but not limited to DNSSEC, is merely weakly secure
and is subject to MitM attacks.

						Masataka Ohta

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Aug 2008 08:55:26 -0700

> when you say that the security of the DNS channels through zones

Ohta-san, the way argument works is that you make a statement, and  
then you give a reason why it's true.   And then if I agree with your  
reason, and agree that your reason applies, I have to agree with your  
statement.   Just making a statement isn't enough - if we do that,  
then we wind up just contradicting each other over and over, and never  
coming to a conclusion.

The problem with your thinking here is that it's _always_ true that if  
the server for a zone is pwned, you can't trust the contents of the  
zone or subzone of that zone, because the person who pwned the server  
can arbitrarily modify the data the server serves.

With DNSSEC, however, there are two differences.   First of all, if  
the server has not been pwned, then bogus data inserted by a third  
party will be detected.   This is because the zone has been signed,  
and there exists a validation path that can be used to verify that  
signature.

The second difference is that with DNSSEC, the mere fact that the  
server has been pwned does not *necessarily* mean that the signing key  
has been revealed.   This is because the administrator has a choice as  
to where to do zone signing - it need not be done on the same machine  
that serves the zone.   So in the case of DNSSEC, a sufficiently  
paranoid security policy protects against a vulnerability that PODS  
simply cannot protect against.

There are still ways to forge the contents of a DNS zone.   But they  
all involve getting access to the signing key for that zone.   So yes,  
DNSSEC is not a panacea.   If you ever thought that I was arguing that  
it is, please stop trying to convince me of that - I already realize  
that that is the case.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 26 Aug 2008 08:56:24 +0900

Ted Lemon wrote:

> all involve getting access to the signing key for that zone.

Wrong.

A forged signature in an ancestor zone of the target zone is
enough.

The ancestor zone is the place upon where a trivial MitM attack
works.

> So yes, DNSSEC is not a panacea.

>> when you say that the security of the DNS channel doesn't matter.

Now, you can see that human factors of DNSSEC channel through zones
does matter.

So, we can agree that PKIs, including DNSSEC, is seriously
discounting the importance of human factors.

With the agreement, the only thing we can do is to accept that
human management of DNS, including DNSSEC, is not very secure.

							Masataka Ohta

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Aug 2008 23:17:46 -0700

> The ancestor zone is the place upon where a trivial MitM attack

Right.   If you get the signing key for .com, you can forge anything  
under .com. If you get the signing key for fugue.com, you can sign  
anything under fugue.com.   And if you get the CA signing key one of  
the major CAs, you can generate new certs for whatever bank you want  
to spoof.

Right now, there simply isn't any protection against forged DNS  
information.

So DNSSEC is not a panacea, and certainly anybody who is running a  
zone that acts as a trust anchor for important zones below it should  
have a security policy that's appropriate for the level of trust being  
invested in them.

But this has nothing to do with the human factors argument I brought  
up, so I'm not sure why you mention it.   I don't think there is  
anybody on this mailing list at this point who does not understand how  
zones are signed, or what trust anchors do.

My point about human factors is that if you can make it much harder to  
forge a domain name, then this makes a lot of security downgrade  
attacks based on human factors (that is, tricks) much harder to carry  
out.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 26 Aug 2008 06:56:08 -0700

At Mon, 25 Aug 2008 23:17:46 -0700,
> attacks based on human factors (that is, tricks) much harder to carry  

I'm sorry but, I still don't understand this argument, since many
of the human factors tricks against TLS depend on getting the
user to override the mechanical checks. Are you arguing that
DNSSEC doesn't permit that kind of override or something else?

-Ekr

---

From: Ted Lemon <[email-masked]>
Date: Tue, 26 Aug 2008 08:26:52 -0700

> DNSSEC doesn't permit that kind of override or something else?

DNSSEC makes it harder to convince the browser to throw up a form that  
doesn't submit via SSL, or that submits to a different site via SSL.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 26 Aug 2008 09:04:15 -0700

At Tue, 26 Aug 2008 08:26:52 -0700,
> doesn't submit via SSL, or that submits to a different site via SSL.

Well, I guess this is true, but I think it fixates on a specific
attack modality that isn't currently very important (hijacking) while
ignoring a modality that is currently very important (phishing).
DNSSEC doesn't do anything to stop either of the things you
mention when a phishing attack is in play.

Obviously, we're talking here about what can be done with DNS, but I
would observe that a set of browser mechanisms (e.g., PwdHash) that
reduced your risk from inadvertantly or maliciously being directed to
the wrong site would provide a significantly higher level of
protection against both classes of attack.

-Ekr

---

From: Ted Lemon <[email-masked]>
Date: Tue, 26 Aug 2008 09:30:19 -0700

> protection against both classes of attack.

I agree that the main opportunity to improve the situation is in the  
browser. However, that's a long-term effort.   DNSSEC is also a long- 
term effort, of course, but I have no idea which will bear fruit  
sooner, so I think it's prudent to work on both.  Neither will bear  
fruit if we just sit on our hands.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 26 Aug 2008 09:47:24 -0700

At Tue, 26 Aug 2008 09:30:19 -0700,
> fruit if we just sit on our hands.

I don't believe I said we should just sit on our hands. I trust
you're not suggesting that I did.

-Ekr