Subject: notes accompanying -02 of forgery-resilience draft

From: bert hubert <[email-masked]>
Date: Mon, 18 Feb 2008 22:04:25 +0100

Hi everybody,

I've just posted -02 of draft-ietf-dnsext-forgery-resilience, which has
received quite a bit of love and changes since -01.

Until it appears on the IETF site, please use 
http://ds9a.nl/tmp/draft.html

A summary:

* Included Stub Resolvers (closing ticket 7)
* Added a 'security' section
* strictly made this draft apply to *implementations* that should have
  certain *abilities*. It is up to the operator to choose an implementation
  that does or does not support these abilities, and it is to the operator to
  choose if or not to turn on said abilities.
* added a *note* to the effect that lower TTL values in zones are easier to
  spoof - non-normative
* typos removed
* countermeasures rewritten heavily to be less specific about measures but
  more about results - no discussion on what 'random' means exactly, but focus
  on 'unpredictable'.
* some wording improvements (differences between resolver, nameserver etc)
* document now updates 1034 instead of confusingly claiming to update either
  1034 or 1035 
* added reference to TSIG/IPSEC rfc's as another way to secure
  communications

Click through http://adsl-xs4all.ds9a.nl/cgi-bin/resilience.fcgi/timeline to
see the exct diffs.

It is suggested we do a final round of critical reading with limited and
focused changes before last call.

Kind regards,

Bert Hubert & Remco van Mook

-- 
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: Alex Bligh <[email-masked]>
Date: Mon, 18 Feb 2008 22:05:40 +0000

--On 18 February 2008 22:04:25 +0100 bert hubert 
<[email-masked]> wrote:

>   more about results - no discussion on what 'random' means exactly, but
> focus   on 'unpredictable'.

Next time you are making some changes, you could look out for use
of the word random elsewhere. In some places you really mean "random or
pseudo-random", whereas in other places I think you mean "arbitrary".
For a trivial example, "random authoritative nameserver" in 1.1, but
more perniciously "pick a random port" in the second para of 4.4 should be,
I think, "use an arbitrary port" (whereas the next para is correct, I
think).

Alex

---

From: Federico Lucifredi <[email-masked]>
Date: Mon, 18 Feb 2008 18:17:50 -0500

Found no substance corrections. Stylistically, I would suggest:

- replacing the term "fake data" with something more specific. In most 
cases, something akin to "doctored resource records" would do.

- in 4.3, "several important documents". Suggesting the more specific 
"two Best Current Practice documents".

- in 5, the first paragraph "a curious mathematical phenomenon means..." 
can be rewritten as "a known probability problem, known as the birthday 
paradox, describes the probability..."

I guess this is the editor's job, but I thought I would lend a hand.

The document looks generally good. Nice job!

  Best-Federico

-- 

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

---

From: bert hubert <[email-masked]>
Date: Tue, 19 Feb 2008 21:50:09 +0100

> cases, something akin to "doctored resource records" would do.

Hmm, how about 'unoriginal data'? I see your point, but 'doctored resource
records' doesn't really do it for me either.

> "two Best Current Practice documents".

Done.

> paradox, describes the probability..."

Tricky, how about:

 The so called birthday paradox means that a group of 22 people suffices to
 have a more than even chance of having two or more members of the group
 share a birthday.

> The document looks generally good. Nice job!

Thanks Federico!

	Bert

---

From: bert hubert <[email-masked]>
Date: Tue, 19 Feb 2008 22:05:44 +0100

> I think, "use an arbitrary port" (whereas the next para is correct, I

Thanks for your keen eye on using 'random' vs 'arbitrary' - I've replaced
the two occurrences you found.

We are indeed a bit sloppy wrt 'random' and 'pseudo-random', but I don't
think adding 'pseudo-' in many places will improve things materially.

What do you think?

	Bert

---

From: Federico Lucifredi <[email-masked]>
Date: Tue, 19 Feb 2008 16:55:58 -0500

> records' doesn't really do it for me either.

I see what you mean. I wanted to convey that those are arbitrarily 
manipulated records... maybe "malicious records" ? or simply 
"manipulated records" ?

>  have a more than even chance of having two or more members of the group

It is just the "means" part that is a bit odd. perhaps replacing it with 
"argues" ? "determines" would also work...

"The so called birthday paradox argues that a group of 22 people 
suffices to have a more than even chance of having two or more members 
of the group share a birthday."

>> The document looks generally good. Nice job!

Thank you! -F

--

---

From: Yue Luo <[email-masked]>
Date: Tue, 19 Feb 2008 18:11:48 -0800

I am new to DNS and would appreciate any help with my question.
It seems that the draft assumes that once a record is cached it won't be overwritten until it has expired. I am wondering if this is a requirement in some RFC or a de facto custom that all implementation follows.

Thank you.
Yue

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of bert hubert
Sent: Monday, February 18, 2008 1:04 PM
To: [email-masked]
Subject: notes accompanying -02 of forgery-resilience draft

Hi everybody,

A summary:

Kind regards,

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 20 Feb 2008 08:33:39 +0100

Yue Luo wrote:
| I am new to DNS and would appreciate any help with my question.
| It seems that the draft assumes that once a record is cached it won't
be overwritten until it has expired. I am wondering if this is a
requirement in some RFC or a de facto custom that all implementation
follows.

RFC 2181 section 5.4.1 describes what a server should do when
considering whether to accept an RRSet in a reply, or
retain an RRSet already in its cache instead.

So, sometimes it will stay in the cache, sometimes be overwritten.

Best regards,
~   Wouter

---

From: Florian Weimer <[email-masked]>
Date: Wed, 20 Feb 2008 08:39:57 +0100

> of the group share a birthday."

Oh, and isn't the magic number 23? 8-)

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: bert hubert <[email-masked]>
Date: Wed, 20 Feb 2008 08:59:06 +0100

> Oh, and isn't the magic number 23? 8-)

Correct :-)

-           The so called birthday paradox means that a group of 22 people
suffices to have a more than even chance 
+           The so called birthday paradox implies that a group of 23 people
suffices to have a more than even chance 

Done.

---

From: bert hubert <[email-masked]>
Date: Wed, 20 Feb 2008 09:02:05 +0100

On Tue, Feb 19, 2008 at 06:11:48PM -0800, Yue Luo wrote:
> It seems that the draft assumes that once a record is cached it won't be
> overwritten until it has expired. I am wondering if this is a requirement
> in some RFC or a de facto custom that all implementation follows.

The data can sometimes be refreshed, but it is not actively refreshed
usually. If an updated copy comes in however, it is generally not ignored.

	Bert

---

From: Alex Bligh <[email-masked]>
Date: Wed, 20 Feb 2008 10:56:15 +0000

Bert,

> think adding 'pseudo-' in many places will improve things materially.

I don't think the distinction between pseudo-random and random is useful
in general for this (perhaps you could even define random
to include 'pseudo-random' somewhere). The fact it's used in some places
and not others probably adds to confusion, as it creates a false
distinction (i.e. 'the authors have said random for X, but random or
pseudo-random for Y, does that mean my PRNG can't be used for X?').

The one type of reference you would want to avoid is saying something
like "the random number generator should be designed so one cannot
guess its output given [set of circumstances]". That is tautological
as by definition one cannot guess the output of a truly random
number generator under ANY set of circumstances. But even this flaw
would be avoided by defining random to include "the characteristics
of a pseudo-random number generator appropriate to the task
described" (or similar), which leaves room for the "appropriate"
to be defined by usage.

Alex

---

From: Yue Luo <[email-masked]>
Date: Wed, 20 Feb 2008 09:39:10 -0800

I am thinking about an attacker manufacturing a reply similar to section 6.2.7 in RFC 1034 in order to attack c.isi.edu.   What should the server do with the c.isi.edu A record in the answer?  Should the server put the record into cache (and overwrite existing c.isi.edu A record if any)?

It seems that an implementation needs to be very careful when dealing with similar situations.  Otherwise, TTL is not effective in reducing the vulnerability window.  It would be very helpful if more discussion and guideline could be provided in the document.

Thank you.
Yue

-----Original Message-----
From: bert hubert [mailto:[email-masked]]
Sent: Wednesday, February 20, 2008 12:02 AM
To: Yue Luo
Cc: [email-masked]
Subject: Re: notes accompanying -02 of forgery-resilience draft

        Bert