Subject: dnsext-forgery-resilience-02

From: Wouter Wijngaards <[email-masked]>
Date: Thu, 13 Mar 2008 14:17:31 +0100

Hi,

A review of draft-ietf-dnsext-forgery-resilience-02.txt

Overall, the direction of the document is a good thing. And security is
increased by following recommendations. But the tone, and wording I do
not agree with, and are used too broadly (see below).

I think this document is better off as a BCP or for-your-information
document, than as a standards track. It recommends best use for getting
forgery resilience, without specifying protocol elements.

Therefore, from the Abstract, the third paragraph should be removed. (By
describing ... updates RFC 1034).

section 2 says
~   It should be noted that the most commonly used resolver currently
~   does not perform as well as possible in this respect, making this
~   document of urgent importance.
Look, bashing some implementation is not very nice. If you want someone
to implement, ask them. Reword to 'most resolvers do not perform well'.

section 3 says
~   5.  It is the first answer to match the previous four conditions.
I think point 5 should be removed. There are no rules preventing you
from accepting a later response, and I do not want this document to make
one.

Section 4.3 Matching the source address of the authentic answer
This is an obvious place to mention the banding-RTT idea. I cannot
provide text for it, because I do know know it fully yet. So, I would
appreciate text about the RTT banding here to fixup!

4.5 says
~   Once any packet has matched the previous four conditions, no further
~   answers should be accepted.
Again, I do not think a rule against listening for multiple answers
should be advocated, it is even against the spirit of this document
(forgery resilience). Reword to
Most resolvers accept the first packet to match the conditions, and no
further answers are accepted.

4.5 also says
~   This means that the third party has a limited time in which to inject
~   its spoofed answer, typically in the order of at most 100ms.
Should say that the time you have depends on the speed with which the
authority server is responding. This means also that by choosing a
faster authority server the time window for a spoof attack is decreased.
And this is at odds with the rtt-banding idea (I think). I think this
conceptual tradeoff needs to be documented.

5. Birthday attacks, says
~   An attacker can benefit from this exact phenomenon if it can force
~   the target resolver to have multiple outstanding questions at any one
~   time for the same domain to the same authoritative server.
Shouldn't those be the same questions? Or does this also hold when there
are multiple, different questions outstanding at one time for the same
zone to the same authoritative server?

9. Countermeasures, says
~   Additionally, resolver implementations MUST have the ability to:
I believe these are recommendations for resilience. I disagree with
MUST. Change to 'are more resilient if they have the ability to:'

and says
~      (53, or > 1024) of ports that is as large as possible;
as large as possible is not good. Grabbing every possible port is a
denial of service attack on the server itself, for having ports for
other purposes. I.e. with 65000 outstanding queries, this is not a good
recommendation. Instead, recommend that a larger range of ports results
in more spoof resilience. And the tradeoff with other port usage can
then be made.

It says:
~   o  Assure that its choices of port and ID cannot be predicted by an
~      attacker having knowledge of its (pseudo-)random generator.
I do not believe an implementation can have an ability to assure its ID
choices cannot be predicted. Including a rng-breaking test into the
resolver implementation is not helpful. Instead recommend to use a
(pseudo)random generator to generate ID and port choices that is hard to
predict.

It says
~   If a resolver sends out multiple equivalent questions to any
~   authoritative server, before receiving an answer, all MUST have
~   identical ID, source address and source port.
Again, I disagree with the MUST. For example; not reply at all is
received. Then the next day another same query comes in from a client -
and a new outgoing query is sent to the server - this can reuse the same
ID, but can also be a new random ID. It is senseless to keep track of
the IDs for all failed queries for which there has been no answer.
Also MUST language is inappropriate I think. The protocol is not harmed.

Make a recommendation for resilience:
Having multiple queries outstanding at the same time to a server with
different IDs is not good for resiliency. The recommendation is to not
have this happen, the same ID can be used.

Then follow two uses of SHOULD. I disagree with SHOULD. Instead make a
recommendation for resiliency. It is more resilient to use an
authoritative server with a trust relationship. It is more resilient for
stub resolvers to use TSIG or IPSEC when communicating with their
recursive resolver.

10. security considerations.
I think that this document is almost completely useless when DNSSEC is
deployed. It may save some calculation by being able to throw away
spoofed packets, but the spoofing is not a DoS risk at this point.
Therefore, the benefit is minimal, in the sense that response time in
the presence of spoofing is better. As such, the urgency when DNSSEC is
in use of all the above suggestions is also low. This is another reason
why uppercase MUST and SHOULD is not appropriate in this document.

It says
~   A resolver that does not implement the recommendations outlined above
~   can easily be forced to accept
Well, this is a function of implementation, but also the operational
choices by the operator that configures the resolver, i.e. if it is
implemented but turned off. As such, maybe an operational recommendation
is better.

Best regards,
~   Wouter

--
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: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 13 Mar 2008 09:57:19 -0400

On Thu, Mar 13, 2008 at 02:17:31PM +0100,
 Wouter Wijngaards <[email-masked]> wrote 

> (pseudo)random generator to generate ID and port choices that is hard to

That's what the first versions of the draft were saying (I suggested
also to add a reference to RFC 4086) and I believe the general
consensus was that it was bad to recommend a technique,
(pseudo-)random generation, instead of a goal, unpredictability. Check
the archives.

---

From: Wouter Wijngaards <[email-masked]>
Date: Thu, 13 Mar 2008 15:29:54 +0100

Stephane Bortzmeyer wrote:
| On Thu, Mar 13, 2008 at 02:17:31PM +0100,
|  Wouter Wijngaards <[email-masked]> wrote
|  a message of 138 lines which said:
|
|> It says:
|> ~   o  Assure that its choices of port and ID cannot be predicted by an
|> ~      attacker having knowledge of its (pseudo-)random generator.
|> I do not believe an implementation can have an ability to assure its ID
|> choices cannot be predicted. Including a rng-breaking test into the
|> resolver implementation is not helpful. Instead recommend to use a
|> (pseudo)random generator to generate ID and port choices that is hard to
|> predict.
|
| That's what the first versions of the draft were saying (I suggested
| also to add a reference to RFC 4086) and I believe the general
| consensus was that it was bad to recommend a technique,
| (pseudo-)random generation, instead of a goal, unpredictability. Check
| the archives.

Well I agree with that, but I am saying something else. The draft is
saying the implementation must assure that its choices ...
Instead, better text is. The implementation is more resilient when the
ID and port numbers are more unpredictable. What assurance can an
implementation give? Must they be digitally signed by a trusted 3rd
party? (that is what I can read in the current draft text).

Best regards,
~   Wouter

---

From: Ben Laurie <[email-masked]>
Date: Fri, 14 Mar 2008 22:29:26 +0000

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

> (pseudo)random generator to generate ID and port choices that is hard to

I don't understand this. You are saying that to fix the predictability 
of a PRNG, use a PRNG instead?

Good PRNGs are not predictable, btw, so long as they are fed enough entropy.

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: bert hubert <[email-masked]>
Date: Sat, 15 Mar 2008 15:13:31 +0100

> forgery resilience, without specifying protocol elements.

Wouter, thanks for your keen reading of the document! I previously feared a
lack of WG-attention. Better late than never.

I'm not very knowledgeable of the exact differences between RFC, BCP,
standard and FYI. FYI seems to light though.

> to implement, ask them. Reword to 'most resolvers do not perform well'.

This isn't meant to bash but simply to state a fact. I reworded it to:

 It should be noted that the most commonly used resolvers currently do not
 perform as well as possible in this respect, making this document of urgent
 importance.

To spread the opprobium a bit.

> from accepting a later response, and I do not want this document to make

Multiple people have mentioned this, but it is in fact rather crucial. If
the window is left open for further answers, all the more chance for a fake
answer to creep in.

I think what you mean is:

<t>It is the first answer to match the previous four, plus possible
additional, conditions.</t>

This leaves room for additional restrictions, perhaps imposed by smarter
resolvers, but still indicates that once a vald answer (by some metric) is
seen, other answers should be considered extraneous.

> appreciate text about the RTT banding here to fixup!

See my previous message (in time) to Paul Vixie regarding RTT-banding.

> further answers are accepted.

I've added the same 'additional conditions' clause.

> authority server is responding. This means also that by choosing a

Added wording to this effect.

> zone to the same authoritative server?

Domain as different from 'zone', so the domain is the question in this case.

> MUST. Change to 'are more resilient if they have the ability to:'

I politely disagree. 

> in more spoof resilience. And the tradeoff with other port usage can

This is reflected in 'as possible', which implies 'not bringing down the
server'. Using a range does not mean actually hogging the whole range.

> (pseudo)random generator to generate ID and port choices that is hard to

I'm in full agreement with Ben Laurie's response on this section.

> deployed. It may save some calculation by being able to throw away

Indeed - this document is about the "interim period". Hence the somewhat
strong wording. 

The changes based on your message above can be found in
http://adsl-xs4all.ds9a.nl/cgi-bin/resilience.fcgi/changeset/17

Thanks!

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

---

From: bert hubert <[email-masked]>
Date: Sat, 15 Mar 2008 15:59:40 +0100

On Sat, Mar 15, 2008 at 10:39:09AM -0400, Edward Lewis wrote:
> At 15:13 +0100 3/15/08, bert hubert wrote:
> 
> Or ("all the more chance") for the real answer to creep in.  The 
> point is, there's no guarantee that the first or last arriving answer 
> is more legitimate than any other arriving answer.

Ok, point taken.

The 'no further answers' thing is mentioned twice, both in non-normative
context describing the current state of affairs.

I think there is little controversy that *current* nameservers all wait for
an acceptable answer to arrive, and then stop listening.

How about the following modification, which further tones down the normative spirit:

@@ -229,16 +229,18 @@
   using the ID field in the response.
            </artwork>
          </figure>
-         <t>DNS data is accepted by a resolver if and only if:
+         <t>DNS data is to be accepted by a resolver if and only if:
            <list style="numbers">
              <t>The question section of the reply packet is identical to that of a question packet currently waiting for an answer</t>
              <t>The ID field of the reply packet matches that of the question packet</t>
              <t>The answer comes from the same network address the question was sent to</t>
              <t>The answer comes in on the same network address, including port number, as the question was sent from</t>
-             <t>It is the first answer to match the previous four, plus possible additional, conditions.</t>
            </list>
          </t>
          <t>
+           In general, the first answer matching these four conditions is accepted.
+         </t>
+         <t>
            If a third party succeeds in meeting the first four conditions before the answer from the authentic answer does so,
            it is in a position to feed a resolver fabricated data. When it does so, we dub it an attacker,
            attempting to spoof in fake data.
@@ -368,7 +370,7 @@
          <section title="Have the answer arrive before the authentic answer">
            <t>
              Once any packet has matched the previous four conditions (plus possible additional conditions),
-             no further answers should be accepted.
+             no further answers are generally accepted.
            </t>
            <t>
              This means that the third party has a limited time in which to inject its spoofed answer, typically in the

?

---

From: Edward Lewis <[email-masked]>
Date: Sat, 15 Mar 2008 10:39:09 -0400

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

Never confuse activity with progress.  Activity pays more.

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Sat, 15 Mar 2008 16:15:25 +0100

Hi Bert,

For your questions,

bert hubert wrote:
| This isn't meant to bash but simply to state a fact. I reworded it to:

Much better

|> section 3 says
|> ~   5.  It is the first answer to match the previous four conditions.
|> I think point 5 should be removed. There are no rules preventing you
|> from accepting a later response, and I do not want this document to make
|> one.
|
| Multiple people have mentioned this, but it is in fact rather crucial. If
| the window is left open for further answers, all the more chance for a
fake
| answer to creep in.
|
| I think what you mean is:
|
| <t>It is the first answer to match the previous four, plus possible
| additional, conditions.</t>
|
| This leaves room for additional restrictions, perhaps imposed by smarter
| resolvers, but still indicates that once a vald answer (by some metric) is
| seen, other answers should be considered extraneous.

Yes that rewording leaves room for listening for multiple answers. Thank
you.

|> Section 4.3 Matching the source address of the authentic answer
|> This is an obvious place to mention the banding-RTT idea. I cannot
|> provide text for it, because I do know know it fully yet. So, I would
|> appreciate text about the RTT banding here to fixup!
|
| See my previous message (in time) to Paul Vixie regarding RTT-banding.

Excellent. Well, 'make them more random' should certainly be in there.
Giving an idea to go about implementing ('take a band of 100 ms'), is OK
too; but I agree with you that it should not be overly specific, as long
as randomness results.

I was a bit surprised you say that since the MUST issue (see below) is
exactly the same concern about over specifying the implementation.

|> 5. Birthday attacks, says
|> ~   An attacker can benefit from this exact phenomenon if it can force
|> ~   the target resolver to have multiple outstanding questions at any one
|> ~   time for the same domain to the same authoritative server.
|> Shouldn't those be the same questions? Or does this also hold when there
|> are multiple, different questions outstanding at one time for the same
|> zone to the same authoritative server?
|
| Domain as different from 'zone', so the domain is the question in this
case.

But the next section or page contains use of the word domain as 'zone'.
Please change the word domain to something more descriptive (in this
case and the other case). Domain -> query name, or question.

|> 9. Countermeasures, says
|> ~   Additionally, resolver implementations MUST have the ability to:
|> I believe these are recommendations for resilience. I disagree with
|> MUST. Change to 'are more resilient if they have the ability to:'
|
| I politely disagree.

That is a bit short. I think this is an important issue.
I do not support this document with MUST on the standards track.
The burden of these measures is not required, only for spoof resistance,
and spoof resistance may become a non-issue, or be a non-issue in
certain situations or environments; that I why I advocate changing the
wording to recommendations for more resiliency in the current practice.

|> and says
|> ~      (53, or > 1024) of ports that is as large as possible;
|> as large as possible is not good. Grabbing every possible port is a
|> denial of service attack on the server itself, for having ports for
|> other purposes. I.e. with 65000 outstanding queries, this is not a good
|> recommendation. Instead, recommend that a larger range of ports results
|> in more spoof resilience. And the tradeoff with other port usage can
|> then be made.
|
| This is reflected in 'as possible', which implies 'not bringing down the
| server'. Using a range does not mean actually hogging the whole range.

I did not read it like that. I think the text is vulnerable to
misinterpretation.

|> It says:
| I'm in full agreement with Ben Laurie's response on this section.

There is a grammar problem here. I am looking at 'who MUST do this' and
everyone else is looking at PRNG vs Entropy.
Your bullet points are preceded with 'the implementation MUST'.
This point raises issues to be taken by the *implementor*.
Please reword for the grammar, I seem to have failed to make it better.

To repeat, the PRNG and real randomness that everybody seems to stumble
over is not my concern at all (that is to say, I agree already).

|> 10. security considerations.
|> I think that this document is almost completely useless when DNSSEC is
|> deployed. It may save some calculation by being able to throw away
|
| Indeed - this document is about the "interim period". Hence the somewhat
| strong wording.

Well I strongly disagree with that strong wording. After DNSSEC
deployment, the strong wording leaves resolvers with a burden of
implementation troubles (catching ports, tough (P)RNG requirements,
doing odd stuff to qnames) that is simply not required any more. I would
like to change those MUSTs, so that in the longer future than today and
tomorrow, implementations are not forced to needlessly implement this.

Thanks for the quick editor function. The recommendations are good;
certainly for the 'interim period', so I think it is a good idea to
write them down.

Best regards,
~   Wouter

---

From: bert hubert <[email-masked]>
Date: Sat, 15 Mar 2008 16:43:48 +0100

> case and the other case). Domain -> query name, or question.

Reworded to:
 An attacker can benefit from this exact phenomenon if it can force the
 target resolver to have multiple equivalent outstanding questions at any one
 time to the same authoritative server.

I always mess up DNS wording..

> I did not read it like that. I think the text is vulnerable to

Added 'and practicable', I hope this clarifies things enough.

> everyone else is looking at PRNG vs Entropy. Your bullet points are
> preceded with 'the implementation MUST'. This point raises issues to be
> taken by the *implementor*. Please reword for the grammar, I seem to have
> failed to make it better.

Hmm, I think I have improved things, but I'm not sure if this addresses the
issue.

++++++++
<list>
<t>Use an unpredictable source port for outgoing queries from
a range (53, or &gt; 1024) of ports that is as large as possible and
practicable;</t>

<t>Use multiple different source ports simultaneously in case
of multiple outstanding questions;</t>

<t>Use an unpredictable query ID for outgoing queries, utilizing 
the full range available (0-65535);</t>
</list>

<t>
In case these abilities are enabled, the implementation MUST
strive to have its choices of source port and question ID remain
unpredictable, even if an attacker has knowledge of its (pseudo-)random
generator.
</t>
+++++++

This states the desired result, and the effort that should be taken, but
does not mandate the use of mathematically proven perfect PRNGs (which I
doubt exist - hard to prove a negative).

> deployment, the strong wording leaves resolvers with a burden of

In this message, I've only addressed issues besides 'MUST' and 'after
DNSSEC' deployment, which I hope we can address after the editorial things
have settled down.

> certainly for the 'interim period', so I think it is a good idea to

Perhaps we could add wording that waives these rules for resolvers that
otherwise validate answers?

	Bert

---

From: [email-masked]
Date: Sun, 16 Mar 2008 04:23:20 +0000

On Sat, Mar 15, 2008 at 04:15:25PM +0100, W.C.A. Wijngaards wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> |

	listening for multiple answers was the reason for the
	creation of the DISCOVER opcode ... QUERY is really targeted
	to a single qualifying answer.  Is perfectly rational to 
	expect multiple, apparently valid answers to a single query
	and having to use other metrics, besides DNS to sort the 
	answers.