Subject: new draft of Forgery Resilience posted - summary of changes

From: bert hubert <[email-masked]>
Date: Mon, 23 Jun 2008 19:59:38 +0200

Hi everybody,

Happy 25th birthday of DNS! I penned a huge message describing my thoughts
on this anniversary, but decided instead to focus on the draft.

I've just posted -04 of the Forgery Resilience draft. It has just appeared
on http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience-04

Many wg-members have submitted heaps of feedback, most of which I was able
to work into the draft; some of which was contrary to earlier and equally
weighty feedback, so I declared stalemate on that.

Most of the changes came from this message
http://marc.info/?l=namedroppers&m=121190105420696&w=2 by Peter Koch. Other
suggestions have come from Andrew Sullivan.

Exact changes can be viewed on: http://is.gd/E2B

A lot of wording has been improved - for example, 'resolver' is now defined
as equal to a full service resolver as mentioned in RFC 1123. Questions and
answers have been replaced by queries and responses. The 'caching resolver'
is gone.

Some invalid responses have instead become packets, some domains have become
domain names, some domains have become zones - all bringing this document in
line with accepted DNS parlance.

Many chapters have received more descriptive names ('Countermeasures' ->
'Recommended countermeasures'), the security section now explicitly states
what this draft recommends.

RFC 2181 has been added as a reference, as has
draft-ietf-dnsop-reflectors-are-evil.

Finally, TCP fallback when a spoofing attempt is detected has been added as
an allowable strategy.

Open questions are: 
	1) MUST/SHOULD/MAY in many places

	2) It has been pointed out that this is not an operational document,
and hence no operational recommendations are made. Instead, recommendations
are made for implementors. However, it has also been pointed out that
operational recommendations should be made. It is unclear however where
these operational guidelines should live. Perhaps the relevant working group
can send text. The chairs agree that strictly speaking this is outside the
scope of this document, but if a draft paragraph is posted it will be
reviewed for suitability.

Please let me know your thoughts on this version!

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

--
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: Olafur Gudmundsson <[email-masked]>
Date: Mon, 23 Jun 2008 16:35:23 -0400

Thanks Bert,

Unless someone raises issues with this version I plan on starting WGLC
later this week.
As for the operational considerations, IMHO that is outside the scope of the
document, but in the words of my predecessor "Send text" apply.

         Olafur

---

From: Suresh Krishnaswamy <[email-masked]>
Date: Wed, 25 Jun 2008 13:07:50 -0400

I support this draft, but I do have a couple of suggestions:

On page 4, it is mentioned that:
   It should be noted that even when all measures suggested below are
   implemented, protocol users are not protected against third parties
   with the ability to intercept, change or inject packets sent to the
   resolver.

I'm wondering what "inject packets sent to the resolver" means in  
this context.
If this refers to the close-in attack scenario where an attacker is  
able to view
the outbound requests as they are sent out, craft a response packet, and
send it to the resolver before the real answer arrived, I'd like this  
to be stated
more clearly.  Specifically, we should note that spoofing of  
responses is
trivial when the attacker is able to sniff/inspect the packet sent
out by the resolver even when all the guidelines sugested in this  
document
are followed. This must also be mentioned in the security considerations
section.

Secondly, some of the text in the document creates the impression that
DNSSEC is still in the development stage. I'd suggest the following  
changes:

i) Replace following text on page 3, para 7:
                                             ...  Although the DNS
   community is working hard on finalising and implementing a
   cryptographically enhanced DNS protocol, steps should be taken to
   make sure that the existing use of DNS is as secure as possible
   within the bounds of the relevant standards.

   with:

   While DNSSEC ( see [RFC4033] and beyond)
   mitigates most of these threats, steps should be taken to
   ensure that the existing use of DNS is as secure as
   possible within the bounds of the relevant DNS standards, even
   without the use of DNSSEC.

ii) Replace following text on page 4, para 1:

   ...
   protocol specifications.  The following also specifies new
   requirements to make sure the Domain Name System can be relied upon
   until a more secure protocol has been standardised and deployed.

   with:

   protocol specifications.  The following also specifies new
   requirements to make sure the Domain Name System can be relied upon
   until DNSSEC is more widely deployed.

iii) And, remove "under development" in the last para in Page 4:

   For protocol extensions under development that offer protection
   against these scenarios, see [RFC4033] and beyond.

Suresh

---

From: bert hubert <[email-masked]>
Date: Wed, 25 Jun 2008 22:53:33 +0200

> I support this draft, but I do have a couple of suggestions:

Thanks!

Although I am grateful for your suggestions, I will only be making very
minimal changes to the draft. The document has been going to and fro for the
past 2+ years now, so I'm only removing blatant errors at this stage.
Anything else must be absolutely uncontroversial.

> I'm wondering what "inject packets sent to the resolver" means in this
> context. If this refers to the close-in attack scenario where an attacker
> is able to view the outbound requests as they are sent out, craft a
> response packet, and send it to the resolver before the real answer

Yes.

I've changed the above to:

 "It should be noted that even when all measures suggested below are
  implemented, protocol users are not protected against third parties with the
  ability to observe, modify or inject packets in the traffic of a
  resolver."

The English sounds worse though. I've also strenghtened the security section
wording on the benefits of real cryptographical security:

 "Recommendations found above should be considered complementary to possible
  cryptographical enhancements of the domain name system, which protect
  against a larger class of attacks."

> DNSSEC is still in the development stage. I'd suggest the following [..]

Off-list, arguments have already been made that it is not uncontroversial if
DNSSEC is finished or in a development state or not. So I respectfully will
not fiddle with the draft because it *might* reflect an impression that
might be true - please see my reasons above.

I fully support the case for better DNS security through cryptographical
means though!

	Bert

---

From: bert hubert <[email-masked]>
Date: Thu, 26 Jun 2008 16:46:45 +0200

Hi everybody,

I've just posted version -05 of the Forgery Resilience draft. It has
appeared on
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience-05.txt

Compared to -04:

	* An IANA section has been added (asking IANA to do nothing)
	* A reference to RFC 2401 has been replaced by a reference to 4301
	  (its successor)
	* Typos (scnearios, reponses, acknowledgements, ountermeasures) were 
	  fixed
	* A tighter description of attacks by third parties that can see your
	  packets was added
	* Added wording that cryptograpical security mechanisms protect
	  against more attacks

Based on feedback so far, and the final small tweaks found in -05, I kindly
request that a WG last call be initiated.

Kind regards,

bert hubert

---

From: Paul Vixie <[email-masked]>
Date: Fri, 27 Jun 2008 15:21:27 +0000

> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience-05.txt

i object to this language:

   o  Question name (compared case-insensitively)

please change it to say:

   o  Question name

otherwise, i echo all of wouter winknaards' suggestions, especially the part
about removing this header:

   Updates: 1034 (if approved)

---

From: Federico Lucifredi <[email-masked]>
Date: Mon, 30 Jun 2008 11:09:21 -0400

Helo Bert,
  I had not seen the drafts since I gave feedback on v2 - the document 
has progressed very nicely, nice work!

  I have a couple of questions:

  In 8, where it is noted that spoofing can be noticed by a watchful 
operator, I would think the resolver should watch as well. Maybe keeping 
track of all the IPs the resolver is getting messages from is too 
serious overhead, but noticing repeated discarded responses (thousands 
of them) to the same query, should only require a single integer... or 
am I missing something ?

  It looks like 9 is going there where it says "if a resolver detects an 
attempt is being made to spoof it...", but then the dropping UPD for a 
TCP query is only under MAY. I can see reasons for this not being a 
MUST, but how about a SHOULD? Is there a reason to have that option so 
weakly worded?

  At the risk of sounding like a DJB fan, has it been considered to give 
a requirement level to source port randomization (SHOULD) ?

  Best -Federico

-- 

_________________________________________
-- "'Problem' is a bleak word for challenge" - Richard Fish
(Federico L. Lucifredi) - [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Mon, 30 Jun 2008 15:42:08 +0000

> track of all the IPs the resolver is getting messages from is too serious
> overhead, but noticing repeated discarded responses (thousands of them) to
> the same query, should only require a single integer... or am I missing
> something ?

how many single integers would we keep, as a quota matter?  if it's 10000
then we can expect attackers to spoof us in a way that churns through all
10000 buckets rapidly enough that no bucket ever gets old enough to count
the real attacks.  (i don't know if this means you're missing something,
but this approach has already been considered and found unacceptable by
several of us here.)

> attempt is being made to spoof it...", but then the dropping UPD for a TCP
> query is only under MAY. I can see reasons for this not being a MUST, but
> how about a SHOULD? Is there a reason to have that option so weakly worded?

this document should make observations, propose some alternatives, and maybe
recommend things, but if at all possible, not extend the DNS protocol by
requiring certain specific actions when certain on-wire patterns are seen.

>   At the risk of sounding like a DJB fan, has it been considered to give a
> requirement level to source port randomization (SHOULD) ?

even those of us who are not DJB fans know that UDP source port randomization
is a good idea, and i for one wish that i had listened to DJB about this when
he first proposed it.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 30 Jun 2008 18:27:50 +0000

> One integer per outstanding query that we are expecting a response for ?

you think an attacker can't run that number up to 10001 or your quota+1?

---

From: Federico Lucifredi <[email-masked]>
Date: Mon, 30 Jun 2008 14:45:01 -0400

> you think an attacker can't run that number up to 10001 or your quota+1?

Oops. I think I tried to condense my thinking too much.

I agree, if we were trying to run counters per-IP, no matter how many 
the buckets, the attacker would be able to exceed it.

But if we are keeping a _single_ counter, per each outstanding query we 
expect a response for, indicating the number of discarded responses to 
this query we have seen, the load is O(n) - one integer per query we 
have outstanding.

I imagine a resolver needs to keep a few hundred bytes of state about 
each query it is expecting responses for, adding 1 integer to each seems 
little harm - and it would allow the responder to switch to TCP behavior 
once a certain threshold is exceeded.

Best -F

--

---

From: Paul Vixie <[email-masked]>
Date: Mon, 30 Jun 2008 18:56:53 +0000

> Oops. I think I tried to condense my thinking too much.

sort of.

> expect a response for, indicating the number of discarded responses to this
> query we have seen, the load is O(n) - one integer per query we have
> outstanding.

by forcing you to make queries to domains i control, and then by delaying the
response to your queries, i can make you have as many outstanding queries as i
want.  if your quota is N then i'll get you to N+1 whenever it suits me.

> I imagine a resolver needs to keep a few hundred bytes of state about each
> query it is expecting responses for, adding 1 integer to each seems little
> harm - and it would allow the responder to switch to TCP behavior once a
> certain threshold is exceeded.

if your "plan B" is expensive, then i will make you do it all the time.

---

From: Federico Lucifredi <[email-masked]>
Date: Mon, 30 Jun 2008 15:10:35 -0400

Got it.

Thanks Paul! -F

--

---

From: Federico Lucifredi <[email-masked]>
Date: Mon, 30 Jun 2008 14:13:30 -0400

[ 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. ]

> requiring certain specific actions when certain on-wire patterns are seen.

ok - that's fair. Although given the success we are having at deploying 
SEC, that maybe should be considered :/

> is a good idea, and i for one wish that i had listened to DJB about this when

:)

  Best -F

-- 

_________________________________________
-- "'Problem' is a bleak word for challenge" - Richard Fish
(Federico L. Lucifredi) - [email-masked]