Subject: [dnsext] Last Call: draft-ietf-dnsext-forgery-resilience (Measures for making DNS more resilient against forged answers) to Proposed Standard

From: The IESG <[email-masked]>
Date: Thu, 2 Oct 2008 15:15:39 -0700 (PDT)

The IESG has received a request from the DNS Extensions WG (dnsext) to 
consider the following document:

- 'Measures for making DNS more resilient against forged answers '
   <draft-ietf-dnsext-forgery-resilience-07.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2008-10-16. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience-07.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15593&rfc_flag=0

--
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: Nicholas Weaver <[email-masked]>
Date: Thu, 2 Oct 2008 16:17:40 -0700

I believe this draft is insufficient:

4.1:  Frankly speaking, with all the mechanisms out there, you must  
assume that an attacker can force queries of the attacker's choosing  
at times of the attacker's choosing, within a fraction of a second in  
almost all cases.  This is not by directly generating a request to the  
server, but by performing some application operation (eg, mail request  
where the SMTP resolver checks it, a Javascript loaded in a victim's  
browser, etc.  Preventing external recursive queries is about as an  
effective defense as a chalk line on the ground saying "do not cross".

More importantly, Time to Live ONLY applies if the cache policy is  
such that there are no Race until win attacks.  In order to eliminate  
race-until-win cases on a particular name, different cache behavior is  
necessary over how currently it is specified in RFC2181.  See http://www.ietf.org/internet-drafts/draft-weaver-dnsext-comprehensive-resolver-00.txt 
  section 10 for details on one such cache policy which can prevent  
all race-until-win attacks.  See http://tools.ietf.org/id/draft-wijngaards-dnsext-resolver-side-mitigation-00.txt 
  section 3.3/3.4 for an approximation of such a policy.

Section 4 also excludes two significant additional entropy sources  
which can't always be used but can often be used: 0x20 matching and  
duplication, since ~32b entropy is only marginally sufficient, but 40b 
+ (achievable through 0x20 and/or duplication) is for protecting the  
cache.

Likewise, section 7-8 explicitly ignore the effects of "race until  
win".  As long as a resolver will accept any additional data from a  
result into the cache, even when in scope (section 6's recommendations  
enable race-until-win attacks), TTL becomes 0 regardless of the actual  
TTL of the record.  This is the real power of the Kaminski attack: it  
is not a reduction in packet-work for the attacker, but a reduction in  
time.

Thus, the paragraph in section 10 is also incorrect: Long TTLs from  
the authority provide no protection unless the recursive resolver  
implements the conservative acceptance policy.  Long TTLs should not  
be encouraged as a security measure, because unless resolver cache  
acceptance is changed, they are not a security measure, but could  
instead cause more failures/difficulties.

And without changing cache acceptance, you must assume that TTL = W in  
sections 7-8.

---

From: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Thu, 09 Oct 2008 12:52:50 -0400

Speaking as Document Shepherd:

Process history:
DNSEXT WG determined that the scope of this document was to
"make it harder to have spoofed answer packet accepted as legitimate answer",
thus the word "resiliency" in the draft name, thus the focus of the
document is 'packet acceptance'.
The topic of 'data acceptance' was judged to be outside the scope of 
the document.

>effective defense as a chalk line on the ground saying "do not cross".

While this is true in general, there are number of situations where
not allowing "out-side" queries helps.
For example:
-  Sites that run separate DNS recursive resolvers/caches
    for mail servers than are used by user population in general.
-  Sites that are able to keep malware off internal hosts limit the
    ability of attackers to issue queries from the inside.

>necessary over how currently it is specified in RFC2181.  See 
>http://www.ietf.org/internet-drafts/draft-weaver-dnsext-comprehensive-resolver-00.txt 
>all race-until-win attacks.  See 
>http://tools.ietf.org/id/draft-wijngaards-dnsext-resolver-side-mitigation-00.txt 

This is outside the scope of the current document, but the WG is starting
work on the 'data acceptance' topic.

>duplication, since ~32b entropy is only marginally sufficient, but 
>40b + (achievable through 0x20 and/or duplication) is for protecting the
>cache.
>

After some discussion in the WG this was explicitly ruled outside the
scope of the document.
For the record most of the attacks I'm seeing are trying to spoof the
root and TLD's using "mostly numeric" domain names, in these cases
x20 provides limited defense.

>is not a reduction in packet-work for the attacker, but a reduction in

This is also in the 'data admission' category not the 'packet acceptance'
but it supports one of my favorite saying: "Optimization is the root cause
of most problems". In this case people were hoping to decrease the
number of queries by learning by a side effect.

>instead cause more failures/difficulties.

This is correct and an important observation.
The document should be updated to reflect this.

>And without changing cache acceptance, you must assume that TTL = W in

also correct, Good observation

Thank you for the review.

         Olafur

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 9 Oct 2008 10:48:00 -0700

>   ability of attackers to issue queries from the inside.

Sites that don't allow their users to visit ANY external web sites...   
An attacker who can get a user to visit a web site of the attacker's  
choosing can cause the DNS resolvers to issue an arbitrary stream of  
requests, EVEN without javascript, just iframes and redirections.

When developing a defensive posture for a DNS resolver, you MUST (in  
the strict standard sense, capitalization is deliberate!) assume the  
attacker can generate an arbitrary request stream: there are simply  
too many vectors which an attacker can do so to consider it plausible  
to shut them down.

Although it may be a good idea for other reasons to prevent external  
use of your institution's recursive resolver, the net security gain is  
negligible.

> x20 provides limited defense.

However, those attacks are only able to work because of the race-until- 
win properties.

The TTLs for these records are relatively long, thus without race  
until win, the attack window is very narrow.

Where 0x20 provides protection is on names with short/0 TTL, which  
includes many rather important sites (googlemail.l.google.com,  
login.yahoo.akadns.net) which also happen to have rather long names.

More important I think is the lack of discussing the semantics of  
duplication.  Duplication is a really powerful tool for increasing  
entropy if you believe 32b of entropy is insufficient and there isn't  
enough additional entropy obtained by 0x20.

Additionally, since you CAN detect that you are under a generic attack  
if you have at least 32b of entropy (just count unsolicited  
responses), you can respond with duplication to effectively double  
your entropy to 64b during the period in which you are under attack.

Thus if the document EXCLUDES 0x20 and duplication, it should  
explicitly state something to the effect:  There are additional  
mechanisms which can be used to increase query entropy in most (but  
not necessarily all) cases, such as 0x20 randomization [cite] and  
packet duplication.  They are deliberately excluded from this document  
for reasons X,Y,Z.

> number of queries by learning by a side effect.

Then there needs to be an explicit reference of the sort:

These equations depend not only on the packet acceptance policy, but  
also the data admission policy.  Unless data admission policies are  
changed to be significantly more restrictive than the current standard  
specifies, race-until-win attacks are possible where an attacker can  
keep attempting to poison a target name regardless of TTL.  As long as  
race-until-win attacks are possible, one MUST assume that TTL = W for  
all defensive calculations.

There is also an assumption that there is duplicate-outstanding- 
request supression (no birthday attacks), which I don't believe is  
explicitly stated.

---

From: Doug Otis <[email-masked]>
Date: Fri, 10 Oct 2008 13:48:44 -0700

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

On Oct 9, 2008, at 10:48 AM, Nicholas Weaver wrote:

>>> 4.1:  Frankly speaking, with all the mechanisms out there, you  
>>> must assume that an attacker can force queries of the attacker's  
>>> choosing at times of the attacker's choosing, within a fraction of  
>>> a second in almost all cases.  This is not by directly generating  
>>> a request to the server, but by performing some application  
>>> operation (eg, mail request where the SMTP resolver checks it, a  
>>> Javascript loaded in a victim's browser, etc.  Preventing external  
>>> recursive queries is about as an effective defense as a chalk line  
>>> on the ground saying "do not cross".
>>
>> -  Sites that run separate DNS recursive resolvers/caches  for mail  
>> servers than are used by user population in general.
> Sites that don't allow their users to visit ANY external web  
> sites...  An attacker who can get a user to visit a web site of the  
> attacker's choosing can cause the DNS resolvers to issue an  
> arbitrary stream of requests, EVEN without javascript, just iframes  
> and redirections.
>
> too many vectors which an attacker can do so to consider it  
> plausible to shut them down.
>
> use of your institution's recursive resolver, the net security gain  
> is negligible.

Agreed.  An MUA or MTA might be used to autonomously generate DNS  
queries to both evil and victim name servers.  There are MUA plugins  
that will also attempt to resolve email path registration records with  
a sizable series of DNS transactions for A, AAAA, or MX records.  The  
script-like resolution process can be directed by a cached resource  
record, where subsequent transactions can be modulated by a macro  
employing the email-address of originator's local-part (MAIL-FROM or  
PRA).  A sequence of 100 transactions can be controlled by an attacker  
that are directed to both evil and victim name servers where neither  
are directly referenced by the message.  The sequencing process could  
be instantiated by a routine that is bound to a UDP port, or that  
navigates through a NAT where port diversity might be greatly  
reduced.  Both the poisoning timing and the opportunity would be  
afforded by spam while consuming little of the attackers resources,  
beyond the additional poison.  This could poison the cache used by  
user population as well as the cache used by the MTA.  This approach  
offers the attack two advantages, ample opportunity while also  
overwhelming the authoritative name server.  : (

>>> which can't always be used but can often be used: 0x20 matching  
>>> and duplication, since ~32b entropy is only marginally sufficient,  
>>> but 40b + (achievable through 0x20 and/or duplication) is for  
>>> protecting the cache.
>>
>> After some discussion in the WG this was explicitly ruled outside  
>> the scope of the document. For the record most of the attacks I'm  
>> seeing are trying to spoof the root and TLD's using "mostly  
>> numeric" domain names, in these cases x20 provides limited defense.
>
> However, those attacks are only able to work because of the race- 
> until-win properties.
>

DKIM provides an interesting feature.  It uses arbitrary sub-domain  
names to reference public keys.  Once an attack detects success  
through a number of techniques, poisonous keys can then validate  
signed email sent to any recipient using the same resolver.

> entropy if you believe 32b of entropy is insufficient and there  
> isn't enough additional entropy obtained by 0x20.

There are too many situations, such as the one described, where it  
would be wrong to assume there is 32b of entropy, where a few case  
bits would become fairly significant.  Detecting a possible attack for  
a specific resource (or its hash) and checking for two matching  
answers seems like a better long term solution.

> Additionally, since you CAN detect that you are under a generic  
> attack if you have at least 32b of entropy (just count unsolicited  

The attack detection would need to resolve against each resource  
separately, or this could double the effect of a path registration  
DDoS attack.

> packet duplication.  They are deliberately excluded from this  
> document for reasons X,Y,Z.

Agreed, with the proviso that the detection technique limits  
duplication to that of the attacked resource.

>>> win".  As long as a resolver will accept any additional data from  
>>> a result into the cache, even when in scope (section 6's  
>>> recommendations enable race-until-win attacks), TTL becomes 0  
>>> regardless of the actual TTL of the record.  This is the real  
>>> power of the Kaminski attack: it is not a reduction in packet-work  
>>> for the attacker, but a reduction in time.
>>
>> This is also in the 'data admission' category not the 'packet  
>> acceptance' but it supports one of my favorite saying:  
>> "Optimization is the root cause of most problems". In this case  
>> people were hoping to decrease the number of queries by learning by  
>> a side effect.
>
> changed to be significantly more restrictive than the current  
> standard specifies, race-until-win attacks are possible where an  
> attacker can keep attempting to poison a target name regardless of  
> TTL.  As long as race-until-win attacks are possible, one MUST  
> assume that TTL = W for all defensive calculations.
>

Agreed.

-Doug