Subject: New working group document ?

From: Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]>
Date: Mon, 30 Oct 2006 11:09:47 -0500

The working group has received a request to adopt the following document
as a working group document:
     http://tools.ietf.org/html/draft-hubert-dns-anti-spoofing-00

The chairs would like to have commitment from at least 5 members of
the working group that they will contribute by reviewing and
commenting to this document.

During earlier discussion on this document it was observed in
http://psg.com/lists/namedroppers/namedroppers.2006/msg01220.html

>RFC3833 lists a number of different threats against the DNS, and the
>term "DNS spoofing" is commonly used to refer to at least three of
>them:
>
>   2.1.  Packet Interception
>   2.2.  ID Guessing and Query Prediction
>   2.3.  Name Chaining
>
>The draft covers threat 2.2, "ID Guessing and Query Prediction", in
>excellent detail, but makes no mention of the others.  It would be
>helpful to note in the draft that the term "DNS spoofing" can also
>refer to threats other than those discussed in the draft.

The question is:
Does the working group prefer that the document stay focused on the
issue it is currently addressing or should the scope of the document
be expanded?
If the scope is expanded we would need commitment from working
group members to produce text.

If the document stays focused then, there is opportunity for others
to volunteer to edit working group documents addressing the other two
issues.

         Olafur & Olaf  

--
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: Roy Arends <[email-masked]>
Date: Mon, 30 Oct 2006 17:18:07 +0100

> commenting to this document.

I second the request, and am committed to review and produce text.

> issue it is currently addressing or should the scope of the document

This will follow automatically from the produced text :)

Roy

---

From: bert hubert <[email-masked]>
Date: Mon, 30 Oct 2006 19:06:55 +0100

>     http://tools.ietf.org/html/draft-hubert-dns-anti-spoofing-00

Thanks. There have been around 10 suggestions received already since I first
mentioned this draft on the list, and a number of these suggestions have
been or will be incorporated in the draft. A new version will be available
soon. Nothing drastic has changed however.

> The question is: Does the working group prefer that the document stay
> focused on the issue it is currently addressing or should the scope of the
> document be expanded?

My personal preference is for this draft to remain 'lean and mean', and keep
a highly focussed message: rules for DNS implementors that, if followed,
protect against spoofing ('id guessing'), with additional hints for zone
owners how they can configure their zones for the same purpose. The latter
part might be more of a DNSOP thing, but it would be silly to have two
separate drafts.

> to volunteer to edit working group documents addressing the other two

Yes please. I fully realise a lot of brain cycles are already busy on a
number of other drafts currently tabled, but I hope we can keep things
focussed and get a useful document without too much back and forth.

Thanks for your attention!

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

---

From: Peter Koch <[email-masked]>
Date: Mon, 30 Oct 2006 20:38:47 +0100

> commenting to this document.

after several reads of the document I think it's a good essay about DNS
spoofing and "size" of the threat (given references to 2006's figures), but I'm
not sure what purpose it should serve as a WG document.

Admitted, it collects some of the folklore or implementors wisdom (and might
be the first document that says the query has to be sent back with the
response), but what's the intended status?
I don't see many interoperability issues, so Standards Track might be a tough
road.  Should it be a BCP for implementors? Or is it meant only as an addendum
to RFC 3833 (informational)?

> issue it is currently addressing or should the scope of the document

I'm willing to review but before I commit I'd like to know again what's
the intended outcome?  Clarifications of the base spec, BCP for
implementors, BCP for operators or just documentation?

Apologies for being confused,
   Peter

---

From: bert hubert <[email-masked]>
Date: Mon, 30 Oct 2006 21:23:19 +0100

> implementors, BCP for operators or just documentation?

The purpose is rather grander. As Olafur said in
http://psg.com/lists/namedroppers/namedroppers.2006/msg01236.html :

   <chair-hat off> 
   My gut feeling is that it will be hard to write this or
   similar draft without saying "Updates RFC1035".

        Olafur

As it stands, this draft basically aims to add some wording to RFC 1034 or
1035, plus an explanation why. In this sense it goes beyond a BCP.

RFC 1034 already makes statements like "The resolver should be highly
paranoid in its parsing of responses.  It should also check that the
response matches the query it sent using the ID field in the response.". 

To this we basically add "Resolvers should choose an unpredictable ID, and
use an unpredictable source port for each query".

I'm not well versed enough in RFC terminology to say if this is a
'clarification', or if there is a better status for this draft. 

Thanks for your time.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 30 Oct 2006 15:55:47 -0500

>group members to produce text.

Why is there a need to expand the scope of the 
document?  Why is thoroughly documenting one 
vulnerability not enough?

I would comment that this draft could be edited 
to make a stronger statement.  That would be to 
show what is the minimum needed duration for a 
window of opportunity to have a attack succeed 
for a given available packet rate capacity. 
I.e., if my botnet (uh, not that I have one) 
could send X packets per second for a given 
response size, how long do I need to keep the 
true authoritative servers busy?

What this document does provide is yet another 
reason why something like BCP 38 is needed.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Secrets of Success #107: Why arrive at 7am for the good parking space?
Come in at 11am while the early birds drive out to lunch.