Subject: WGLC summary for draft-ietf-dnsext-forgery-resilience

From: Andrew Sullivan <[email-masked]>
Date: Fri, 18 Jul 2008 16:02:35 -0400

Dear colleagues,

The WGLC has concluded.  Many thanks to the reviewers.

There was lively discussion during the last call, with a number of good
comments. There is a strong WG consensus to advance the document, but
there was interesting debate about which track the document should
follow -- standards or BCP.
The chairs sense that most WG members, while preferring one track 
over the other, are on record as being able to live with either track.

This document is in real strange position, it is "not strictly" required
for interoperabilty but it is "strictly" needed for the safe(r)
behavior of implementations. The IETF standards track documents do not
explicitly address what kind of document this is.

In order to make the strongest possible statement to the non DNS
community that this work is important the chairs will advance this
document as Standards Track.

Current draft states that it updates 1034, this is incorrect it actually
updates 2181. Editor please change that.

Major change:
During the last call some people thought section 9 needed tuning.
After going through the discussion the chairs are proposing
the following replacement of section 9. (need to check

Replacement of section 9:
9. Forgery Countermeasures

9.1 Query matching rules

    A resolver implementation MUST match responses to
    the all of following attributes of the query:
    o Source address against query destination address

    o  Destination address against query source address

    o  Destination port against query source port

    o  Query ID

    o  Question name

    o  Question class and type

    before applying DNS trustworthiness rules (see [RFC2181], section
    5.4.1).   A mismatch and the response MUST be considered
    invalid.

9.2 Extending the Q-ID space by using ports and addresses

  Resolver implementations MUST:

    o  Use an unpredictable source port for outgoing queries from the
       range (53, or > 1024) of available ports that is as large as
       possible and practicable;

    o  Use multiple different source ports simultaneously in case of
       multiple outstanding queries;

    o  Use an unpredictable query ID for outgoing queries, utilizing the
       full range available (0-65535)

   Resolvers that have multiple IP addresses SHOULD use them in an
   unpredictable manner for outgoing queries.

   Resolvers SHOULD favour authoritative nameservers with which a trust
   relation has been established; Stub-resolvers SHOULD be able to use
    TSIG ([RFC2845]) or IPSEC ([RFC4301]) when communicating with their
    recursive resolver.

    In case a cryptographic verification of response validity is
    available (TSIG, SIG(0)), resolver implementations MAY waive above
    rules, and rely on this guarantee instead.

   Proper unpredictability can be achieved by employing a high quality
    random generator, as described in [RFC4086].

9.2.1 Justification and Discussion

         Since an attacker can force a full DNS resolver to send queries
         to the attacker's own name servers, any constant or sequential
         state held by such a resolver can be measured, and it must not be
         trivially easy to reverse engineer the resolver's internal state
         in a way that allows low-cost high-accuracy prediction of future
         state.

         A full DNS resolver with only one or a small number of upstream-
         facing endpoints is effectively using constants for IP source
         address and UDP port number, and these are very predictable by
         potential attackers, and must therefore be avoided.

         A full DNS resolver who uses a simple increment to get its next
         DNS ID is likewise very predictable and so very spoof able.

         Finally, weak random number generators have been shown to expose
         their internal state, such that an attacker who witnesses several
         sequential "random" values can easily predict the next ones.  A
         crypto-strength random number generator is one whose output cannot
         be predicted no matter how many successive values are witnessed.

9.3 Spoof detection and countermeasure

    If a resolver detects that an attempt is being made to spoof it,
    perhaps by discovering that many packets fail the criteria as
    outlined above, it MAY abandon the UDP query and re-issue it over
    TCP.  TCP, by the nature of its use of sequence numbers, is far more
    resilient against forgery by third parties.

Minor changes:
Apply nits that number of people have brought up including
Jelte Jansen, Paul Hoffman, Paul Vixie, Peter Koch, Alex Brown,
Andreas Gustafsson, Jimmei Tatuya.

The editor will post a new version for the working group members
to check if their nits/comments have been addressed.
Week after the document is reposed the chairs will advance the document
to the IESG.

         Olafur & Andrew  

--
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: bert hubert <[email-masked]>
Date: Wed, 30 Jul 2008 21:29:07 +0200

Hello working group,

To my great sadness I won't be able to join you in Dublin, but rest assured
I'll spend quality time with my ten-week old son instead. 

-06 has been posted:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience-06.txt

I've updated chapter 9 as outlined in the posting by Andrew, plus addressed
all nits Peter Koch had open.

Some more below:

> Andreas Gustafsson, Jimmei Tatuya.

I could not find open nits by Jelte, Paul, Paul, Alex Bligh, Andreas or
Jinmei. Additionally, Peter Koch told me he sent me an example which would
fit well in the draft, but I can't find it, but I did promise I'd include
it.

If any of you feels I've ignored any of your nits, please please let me
know.

Finally, I've been doing the math for Kaminksy-style spoofing, it is
interesting. 

I hope to share it with you later tonight. A naive calculation shows we
should not be overly worried, delving into it deeper makes me worry again.

	Bert

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