Subject: draft-ietf-dnsext-forgery-resilience-01.txt

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 10 Nov 2007 19:42:33 -0200

After review, this document seems to me be in a good shape and it
would be a good idea to foresee a WG Last Call for it.

The issues I still have (yes, I will record them on the Wiki)

* a reference (normative?) to RFC 4086 would be a very good idea, with
a link from section 9 "Implementations SHOULD use good random source
to select a Query ID"

* -01 says "TBD: Do we need to talk about stub resolvers?  Does this
draft apply to them?" I believe that the answer is yes. A typical stub
resolver cannot receive unexpected answers (it typically does not
listen for ever on the network) but it still can be fooled when
listening for a reply. In addition, a typical stub resolver should
listen only to the answers coming from the nameservers listed in its
configuration (/etc/resolv.conf on Unix) but I'm not sure they all
do and, anyway, it is not sufficient, the other countermeasures
mentioned in section 9 all apply.

[Soap box: I regret there is no list of changes from previous
versions. It seems most of them are precisions in the Countermeasures
section]

--
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: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 12 Nov 2007 08:59:27 +0100

> versions. It seems most of them are precisions in the Countermeasures

See:

http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-forgery-resilience/
  found via http://tools.ietf.org/wg/dnsext/

--Olaf

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: Florian Weimer <[email-masked]>
Date: Mon, 12 Nov 2007 10:43:06 +0100

> a link from section 9 "Implementations SHOULD use good random source

There is no industry consensus that this is a good idea.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 12 Nov 2007 07:46:23 -0200

On Mon, Nov 12, 2007 at 08:59:27AM +0100,
 Olaf M. Kolkman <[email-masked]> wrote 

> http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-forgery-resilience/

Yes, and there is GNU diff, too. But a hand-written "Changes" section
allows to have a simpler and more synthetic view of the changes,
without spurious diffs (such as the change in the boilerplate that the
tool above noticed).

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 12 Nov 2007 08:05:06 -0200

On Mon, Nov 12, 2007 at 10:43:06AM +0100,
 Florian Weimer <[email-masked]> wrote 

> There is no industry consensus that this is a good idea.

What is not a good idea? "Implementations SHOULD use good random
source to select a Query ID" or "The draft should add a reference to
RFC 4086"?

---

From: bert hubert <[email-masked]>
Date: Mon, 12 Nov 2007 11:12:57 +0100

> There is no industry consensus that this is a good idea.

Can you elaborate? Because it seems to me that having a good source of
random for things we like to be unpredictable is very much an industry
consensus.

Thanks.
	
	Bert

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

---

From: Florian Weimer <[email-masked]>
Date: Mon, 12 Nov 2007 11:30:04 +0100

> source to select a Query ID" or "The draft should add a reference to

The former.  It has been argued that non-repeating query IDs are more
important than good randomness.  I tried very hard to understand this,
but I still don't get it.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 12 Nov 2007 11:49:15 +0100

> but I still don't get it.

Does a sentence like this help clarify:

"The (sequence of) Query IDs SHOULD be unpredictable"
possibly with the addition off:
"e.g. by using a good source of randomness to generate them".

Or is your question more fundamental?

--Olaf

---

From: Florian Weimer <[email-masked]>
Date: Mon, 12 Nov 2007 15:11:10 +0100

> "e.g. by using a good source of randomness to generate them".

I think this is worse because you should reuse query IDs in some cases
(to avoid the birthday paradox when you still accept previous in-flight
queries).

> Or is your question more fundamental?

Oh, let me put this differently: An implementation does not follow
anything close to RFC 4086.  We should figure out why they do this.
Maybe there's a compelling reason, and in that case, the reason really
should be mentioned in the draft.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 12 Nov 2007 14:57:51 +0000

> There is no industry consensus that this is a good idea.

agreed.  there's no consensus that even a ~31 bit pseudo random combination
of source port and query ID is good enough to have confidence that any given
answer was really received from a purported server.

there is also no consensus on the meaning of "good" in the context of "good
random source".  some say arc4random is fine, others say it's too weak.

you could say something like "Implementations SHOULD NOT use query-ID schemes
for which a proof of concept has demonstrated trivial predictability and easy
cache pollution.  NOTE WELL that the definition of 'trivial' changes every
year, and that nothing short of Secure DNS can provide confidence in answers."

---

From: bert hubert <[email-masked]>
Date: Mon, 12 Nov 2007 16:45:35 +0100

> answer was really received from a purported server.

That is correct. The intent of this draft is not to generate the end-all of
DNS security - that might well be DNSSEC, or as you call it 'Secure DNS'.

The intent of this draft is to raise the security bar for the interim period
until DNS gets real cryptography. The draft states as much:

	The current internet climate poses serious threats to the Domain
	Name System.  In the interim period before the DNS protocol can be
	secured more fully, measures can already be taken to make 'spoofing'
	a recursing nameserver many orders of magnitude harder.

	Even a cryptographically secured DNS benefits from having the
	ability to discard bogus answers quickly, as this potentially saves
	large amounts of computation.

> year, and that nothing short of Secure DNS can provide confidence in answers."

Should an implementation chose to use a random generation scheme that
turns out to be predictable, it should be obliged to shift to one that is
not. So the definition of 'trivial' or any other qualifying modifier should
not be a problem.

The upshot of it all is that the chosen query-ID (and source port) SHOULD
NOT be easily predictable.

And I'm sure there is "industry consensus" that having an easily predictable
query-ID is not a good thing.

	Bert

---

From: Tony Finch <[email-masked]>
Date: Mon, 12 Nov 2007 16:28:08 +0000

> but I still don't get it.

You can't just naively pick a query ID at random from the whole 16 bit
space because you'll have ID clashes. You need a scheme that does not
re-use recent IDs too quickly, but this does not mean that you don't
need good randomness.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SOLE: VARIABLE BECOMING NORTHWESTERLY 3 OR 4, OCCASIONALLY 5. SLIGHT OR
MODERATE. MAINLY FAIR. GOOD.

---

From: Florian Weimer <[email-masked]>
Date: Mon, 12 Nov 2007 17:36:23 +0100

* Tony Finch:

> space because you'll have ID clashes.

Why are ID clashes a problem?  Do real-world authoritative servers
misbehave when confronted with them?

This should really be mentioned in the draft.

---

From: Shane Kerr <[email-masked]>
Date: Mon, 12 Nov 2007 18:15:07 +0100

> misbehave when confronted with them?

Well, it's a resolver that picks the query ID, but this is a good question.

The only time you have an actual clash is when you have a duplicate ID+source
IP+source port+destination IP+destination port for a UDP query, because then the
resolver has no way to disambiguate the replies it gets.

Certainly some implementations may have problems with duplicate query IDs, but
that's out of scope for an RFC, IMHO.

- --
Shane

---

From: Paul Vixie <[email-masked]>
Date: Mon, 12 Nov 2007 17:29:51 +0000

> query-ID is not a good thing.

so far, so good.  do we have a winner on the above wording?

---

From: Florian Weimer <[email-masked]>
Date: Mon, 12 Nov 2007 18:33:39 +0100

> Well, it's a resolver that picks the query ID, but this is a good

Yes, and it has to choose them in a way that doesn't trigger bugs in
authoritative servers (or upstream resolvers, if there's a hierarchy).

> resolver has no way to disambiguate the replies it gets.

In a typical setup, this will just look like a duplicate packet.  And
thanks to certain load balancers, you already need to deal with this
situation on the resolver side.

Parallel UDP and TCP queries with the same ID could be a different
matter.

> that's out of scope for an RFC, IMHO.

Does that mean ID collision avoidance is just based on a hunch?  I don't
want to sound disparaging--I just hope that we can get rid of the
additional complexity such a requirement implies.

I agree that if collision avoidance isn't a must, the RFC can be silent
on this issue.

---

From: Tony Finch <[email-masked]>
Date: Mon, 12 Nov 2007 17:42:16 +0000

On Mon, 12 Nov 2007, Florian Weimer wrote:
>
> Why are ID clashes a problem?

I'd expect them to cause in the most benign case delays because of
retries. Or a server might be mistakenly marked as broken, or the client
might get confused and return bogus data. It depends on how the client
disambiguates replies to queries and how paranoid it is.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: NORTHERLY 3 OR 4, OCCASIONALLY 5 LATER IN NORTH. SLIGHT OR MODERATE.
SHOWERS. GOOD.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 12 Nov 2007 12:57:17 -0500

> that's out of scope for an RFC, IMHO.

It's not out of scope for consideration in this discussion, though, is
it?  It seems it'd be relevant to whether a good source of randomness
is what should be recommended.  If some implementation has problems
with duplicate query IDs, then they'll be able to argue that
randomness is the wrong target, I think.

A

-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
jabber: [email-masked]                 +1 416 646 3304 x4110

---

From: Tony Finch <[email-masked]>
Date: Mon, 12 Nov 2007 17:55:59 +0000

On Mon, 12 Nov 2007, Shane Kerr wrote:
>
> The only time you have an actual clash is when you have a duplicate
> ID+source IP+source port+destination IP+destination port for a UDP
> query, because then the resolver has no way to disambiguate the replies
> it gets.

This situation is common for stub resolvers, and for cacheing resolvers
that are doing a lot of lookups against the same zone. Any high-volume
DNS client *will* encounter problems with naive random query IDs.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
WEST FORTIES CROMARTY FORTH TYNE WEST DOGGER: WESTERLY VEERING NORTHERLY 4 OR
5, INCREASING 5 TO 7, PERHAPS GALE 8 LATER IN TYNE AND WEST DOGGER. MODERATE
OR ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD.

---

From: bert hubert <[email-masked]>
Date: Mon, 12 Nov 2007 19:09:15 +0100

> resolver has no way to disambiguate the replies it gets.

Even more - "source ip, source port, destination ip, destination port, id,
qname, qtype" - these all have to match.

Authoritative servers do not look at the id of questions they get, except to
copy them to the answer. 

So duplicate query-IDs are only a problem for the resolver emitting them,
which will then have trouble disambiguating replies - iow, it is buggy.

	Bert

---

From: Tony Finch <[email-masked]>
Date: Mon, 12 Nov 2007 18:23:47 +0000

You should read the following slides for a discussion of how to use good
randomness for packet IDs without causing interop problems. The protocols
are TCP and IP, but similar considerations apply to DNS.

http://www.bsdcan.org/2006/papers/ImprovingTCPIP.pdf

Note that bad randomness will cause the same kinds of interop problems as
good randomness, so there's no harm recommending good randomness.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
MALIN HEBRIDES: SOUTHERLY IN EAST AT FIRST, OTHERWISE NORTHWESTERLY 5 TO 7,
OCCASIONALLY GALE 8 IN HEBRIDES. ROUGH OR VERY ROUGH. RAIN OR SHOWERS.
MODERATE OR GOOD.

---

From: Alex Bligh <[email-masked]>
Date: Mon, 12 Nov 2007 19:38:15 +0000

> re-use recent IDs too quickly, but this does not mean that you don't

I think not. Picking ID's in ascending numerical order (skipping clashes)
would satisfy that, but obviously be less useful than a random scheme
(which also skipped clashes). I am assuming here that there is some
set of IDs for which are dangerous.

I think the problem here is people are trying to describe the mechanism
for allocating ID's etc. rather than what it is desirable to achieve. EG:
  "ID's SHOULD be assigned in a manner that the ability of a third party
   with access wire data to guess ID's on subsequent queries is minimised;
   this could, for instance, be achieved by introducing a pseudo-random
   component into the mechanism used to select the ID".

Alex

---

From: bert hubert <[email-masked]>
Date: Mon, 12 Nov 2007 23:03:44 +0100

> so far, so good.  do we have a winner on the above wording?

From my end, we do. 

In rfc-ese:

  Implementations MUST NOT use Query-IDs that can easily be predicted

or

  Implementations MUST use Query-IDs that are not easily predicted

I'd personally prefer something along the lines of

  Implementations MUST use Query-IDs that are hard to predict

Regards,

Bert

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 12 Nov 2007 20:35:43 -0200

On Mon, Nov 12, 2007 at 11:03:44PM +0100,
 bert hubert <[email-masked]> wrote 

>   Implementations MUST use Query-IDs that are hard to predict

More detailed, with the help of Alex Bligh:

Implementations MUST use Query-IDs that are hard to predict for a
third party with access to wire data. This could, for instance, be
achieved by introducing a random [RFC 4086] or pseudo-random component
into the mechanism used to select the ID

--
Read on /., about MS-Windows error messages:

Your system must meet the requirements to be able to run the Windows
Random Number Generator on Vista. Otherwise, you will need to use
Windows Number Generator Basic. The only number WNGB can generate is
4.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 13 Nov 2007 10:18:10 +1100

> DNS client *will* encounter problems with naive random query IDs.

	It also doesn't help when the OS re-assigns the same port number
	over and over and over until there happens to be a collision
	which just causes it to move onto the next port and repeat the
	process.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Tue, 13 Nov 2007 10:26:57 +1100

> qname, qtype" - these all have to match.

	But not in the error reply space.  The client has to handle
	just getting back the 12 octet DNS header for NOTIMP,
	FORMERR, SERVFAIL etc.  Good answers (includes NXDOMAIN)
	to queries contain the qname and qtype.

	It also has to handle delayed error replies, duplicate error
	replies (possibly due to duplicate queries), etc.
 
> Authoritative servers do not look at the id of questions they get, except to

	Recursive servers do duplicate query suppression.  Remember there
	are often chains of recursive servers.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 12 Nov 2007 20:51:12 -0500

<chair-hat=off>

>into the mechanism used to select the ID

when third party has access to query stream (i.e. wire access) all
bets are off as it sees the query and can forge a single answer.

The issue we are trying to address is: can a third party somehow
observe few sequential queries and from that information
predict future query id's and ports.

         Olafur

---

From: Wouter Wijngaards <[email-masked]>
Date: Tue, 13 Nov 2007 09:56:49 +0100

> disambiguates replies to queries and how paranoid it is.

A quick calculation says that a busy resolver, talking to a
forwarder/cache, with 1000 queries per second, each query takes 500 msec
to be answered, that uses a plain random 16bit ID (no extra ports), has
85% chance of having a duplicate ID outstanding, and thus being unable
to disambiguate the reply. That is pretty high, I think the draft can
say something about avoiding these ID clashes.

Best regards,
   Wouter
PS. formula used, p = 1-exp(-n*n*H/2), with n=500, H=65536.

---

From: Alex Bligh <[email-masked]>
Date: Tue, 13 Nov 2007 09:39:50 +0000

Olafur,

> predict future query id's and ports.

(re your first para) of course, if they have access to *all* wire
data. Equally, IDs being hard to predict where a third party has
access to *no* wire data is not a sufficiently strong solution
(obviously).

I think you might, however, be missing the point. The point is not to
pretend that the originator of the query will thereby gain security if a
third party DOES have access to all wire data, just that if IDs are hard to
predict if a third party DID have access to *all* wire data, then this is
(I think) SUFFICIENT that it is hard (enough) to forge replies etc. when
the third party doesn't have access to *all* wire data (we presume they
might have access to some, e.g. some queries the third party answers
itself).

The reason I picked this threshold was if you imagine the situation
where a third party engineers a situation where the resolver concerned
makes all queries to a server in the control of a third party (e.g.
by making a user visit an html page with a sequence of links in
to addresses located within a domain controlled by him) and then
a single query of the server whose address he wants to fake (e.g.
a short delay then http://www.mybank.example.com/ or whatever),
then in practice the attacker has had access (or hopes he has had
access) to all (recent) wire data and we are hoping he can't
then guess the next ID - i.e. we are hoping the ID is hard to guess
when the third party has had access to 'all wire data'.

You could write "access to all wire data except the putative query
to be made" but clearly the attacker won't have access to something
which has not yet happened, hence my failure to exclude that case
specifically.

Alex

---

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 13 Nov 2007 11:46:21 +0200

> authoritative servers (or upstream resolvers, if there's a hierarchy).

Do you know of any such bugs?  The users of the two recursive DNS
server implementations I have worked on certainly haven't reported
any problems caused by such bugs.

What both of those implementations actually do is to choose the query
ID randomly among the set of query IDs not already in use by
outstanding queries.  This exclusion of already outstanding IDs is
done purely to aid in uniquely identifying the response, not to work
around any known external bug.
-- 
Andreas Gustafsson, [email-masked]

---

From: Alex Bligh <[email-masked]>
Date: Tue, 13 Nov 2007 09:50:37 +0000

> PS. formula used, p = 1-exp(-n*n*H/2), with n=500, H=65536.

1-exp(-n*n/2H) I think you mean. I'm not sure that's right though because
it won't use a random ID, it will use a random ID that is not already
outstanding. In which case the server simply has 500 IDs outstanding
(on average) at any one time out of a maximum possible ID space of 2^16,
which means if the attacker sends in one packet, he'd have a chance
of 0.7% of picking one outstanding. Send in tens of thousands of
packets a second (for instance one with every ID) and you are guaranteed
a match. But you'd also have to match not only the ID, but also the
QNAME etc. If one uses random ports as well, one needs to send in
millions of pps which is (slightly) harder today.

Alex

---

From: Shane Kerr <[email-masked]>
Date: Tue, 13 Nov 2007 11:48:09 +0100

Alex,

Alex Bligh wrote:
> makes all queries to a server in the control of a third party

I think this rationale makes sense. One thing I often find missing from RFCs is
exactly this sort explanation. Maybe including it would be useful?

- --
Shane

---

From: Wouter Wijngaards <[email-masked]>
Date: Tue, 13 Nov 2007 13:26:09 +0100

> 1-exp(-n*n/2H) I think you mean. I'm not sure that's right though because

Yes that formula.

> outstanding. In which case the server simply has 500 IDs outstanding

Well text, suggesting to use a random ID that is not already
outstanding, could be added to the draft to clear up that true 'random
only' is not such a good idea. That is what I meant.

Otherwise, I agree with your analysis.

Best regards,
   Wouter

---

From: Paul Vixie <[email-masked]>
Date: Tue, 13 Nov 2007 14:43:42 +0000

> say something about avoiding these ID clashes.

i don't think the draft ought to mention avoiding id clashes.  as marka
said, some recursive servers do duplicate-suppression, that is, they won't
launch another upstream query if they're already working on one that had
the same <qname,qclass,qtype,clientip,queryid>, and no, <clientport> is
not a factor in that calculation, and yes, rfc1034/1035 permits this.

also, i have in recent years developed (outside of the BIND framework) a
recursive nameserver which, when selecting a <clientport,queryid> for an
upstream query, avoids any that are in use for existing upstream queries.
so the 85% figure shown above may be affecting the performance of my DNS
initiator, since if i get a collision i have to keep trying, but 0% of my
upstream <clientport,queryid>'s duplicate those already in flight.  ever.

this thread appears to have ratholed.  bert proposed language.  are we
there yet?

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 13 Nov 2007 16:15:47 +0100

> this thread appears to have ratholed.  bert proposed language.  are we

You mean:

  "Implementations MUST NOT use Query-IDs that can easily be predicted"

Speaking for myself: I found the discussion helpful to understand the  
issue in depth. Now I am comfortable with the above sentence. And for  
what its worth, the recursive nameserver of which development I am  
sideways involved in follows the behavior you describes too :-)

--Olaf

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 13 Nov 2007 11:04:45 -0500

>   component into the mechanism used to select the ID".

I like this version.  It specifys narrowly the condition one is trying
to avoid, and gives a clue about why one wants to avoid it.  It
provides an example of how to avoid it, but does not prescribe one.

A

---

From: Paul Vixie <[email-masked]>
Date: Tue, 13 Nov 2007 16:26:37 +0000

> provides an example of how to avoid it, but does not prescribe one.

i don't like this version, it overspecifies.  i like bert's version.

---

From: Alex Bligh <[email-masked]>
Date: Wed, 14 Nov 2007 10:02:21 +0000

>   component into the mechanism used to select the ID".

It has been pointed out to me off list that there is an ambiguity,
viz "how much wire data". What I meant was that the it should be difficult
to guess if the malefactor has seen ALL the wire data (bar the packet
being assembled which obviously hasn't yet been set). Being hard to
guess if they have only seen a little is not sufficient (for the
reasons I outlined before).

We could thus change this to "with access to all previous wire data".
Remember we are not trying to guard against the threat of someone
with the wire data of the query packet to be sent (that would require
DNSSEC), we are trying to specify how hard the query ID should be to
guess (I have no strong feelings on this; I think it risks fuelling
Paul's overspecification criticism but does make things easier).

> when the third party has had access to 'all wire data'.

It has been suggested this scenario only represents a snapshot of
queries. The implicit criticism is "why not then require only
that the ID is hard to guess for a malefactor with access to
a recent snapshot of queries". The answer is "because it's
hard to define a recent snapshot with any precision and
requiring that the it is hard to guess if they've seen all
previous data is sufficient (if more than is necessary)".

Paul argues that this overspecifies things. I agree there is a highish
hurdle here. But given we are talking about "minimising ability of
a third party" within a "SHOULD" recommendation, I am not too concerned
by that. Would "ID's SHOULD be assigned in a manner that attempts
to minimise the ability of a third party with access to all previous
wire data to guess ID subsequent queries" be better?

Alex

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 16 Nov 2007 12:55:14 -0200

On Mon, Nov 12, 2007 at 02:57:51PM +0000,
 Paul Vixie <[email-masked]> wrote 
 a message of 24 lines which said:

> there's no consensus that even a ~31 bit pseudo random combination
> of source port and query ID is good enough to have confidence that
> any given answer was really received from a purported server.

As mentioned by Bert, we do not try to achieve the same result as
DNSSEC. We try to raise the bar for the attacker. A sort of
Better-Than-Nothing security.

> there is also no consensus on the meaning of "good" in the context
> of "good random source".  some say arc4random is fine, others say
> it's too weak.

Hence the idea to delegate the whole point to RFC 4086, which is
already written.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 16 Nov 2007 13:00:43 -0200

On Tue, Nov 13, 2007 at 11:48:09AM +0100,
 Shane Kerr <[email-masked]> wrote 
 a message of 29 lines which said:

> I think this rationale makes sense. One thing I often find missing
> from RFCs is exactly this sort explanation.

+1 As long as the rationale is clearly separated from the normative
text (rationales and case studies tend to rot and to be not longer
relevant after a while).

> Maybe including it would be useful?

What do you think of my proposed text?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 16 Nov 2007 12:52:37 -0200

On Mon, Nov 12, 2007 at 08:35:43PM -0200,
 Stephane Bortzmeyer <[email-masked]> wrote 

> More detailed, with the help of Alex Bligh:

New version that I propose, with a clearer separation between the norm
and the rationale (they could even be placed in different sections). I
believe this captures the discussion in the WG and that nothing was
forgotten.

Rule:

Implementations MUST use Query-IDs that are hard to predict for a
third party, even if this third party has access to previous wire
data.

Advice for implementors:

"Hard to predict" Query-IDs could, for instance, be achieved by
introducing a random [RFC 4086] or pseudo-random component into the
mechanism used to select the ID. Be warned that Query-IDs of
outstanding requests should not be reused so a purely random solution
is dangerous.

For instance, a recursive server can have another recursive server
upstream and some recursive servers do duplicate-suppression, that is,
they won't launch another upstream query if they're already working on
one that had the same <qname,qclass,qtype,clientip,queryid>
(<clientport> is not a factor in that calculation).

Rationale:

Predictable Query-IDs are dangerous because they allow the bad guys to
easily spoof responses.

Purely random Query-IDs may lead to problems for the resolver which
emits them, because there will be a high risk of duplicate
IDs. Sorting out duplicated IDs in responses is easy if the response
contains the <qname> and <qtype> but more complicated for errors like
SERVFAIL. So, a possible solution is to choose randomly from the pool
of IDs not currently used by a pending query.

Even without the ability to snoop on the wire, a third party can still
have access to wire data, for instance, where the resolver concerned
makes all queries to a server in the control of a third party (e.g.
by making a user visit an HTML page with a sequence of links in to
addresses located within a domain controlled by him) and then a single
query of the server whose address he wants to fake (e.g. a short delay
then http://www.mybank.example.com/).

Then in practice the attacker has had access (or hopes he has had
access) to all (recent) wire data and we are hoping he can't then
guess the next ID - i.e. we are hoping the ID is hard to guess when
the third party has had access to 'all former wire data'.

---

From: Alex Bligh <[email-masked]>
Date: Sat, 17 Nov 2007 11:56:10 +0000

--On 16 November 2007 12:52:37 -0200 Stephane Bortzmeyer 
<[email-masked]> wrote:

> New version that I propose,

This works for me. I am presuming the "Rationale" section is not
for the RFC but for the list, or we might change "bad guys" to
"attacker" etc.

[ I Had drafted a response saying it may be that duplicating query IDs where
  the rest of the query n-tuple is different is desirable on high volume
  query originators, with some stats to indicate when it might be necessary,
  and rephrased in terms of the necessity of disambiguating responses
  rather than merely saying "dangerous". However, given the difficulties
  with SERVFAIL etc., I concluded that if you stick all this in, you
  are left more with the definition of a problem for an implementers rather
  than implementation advice. On the basis these extra words were thus
  unhelpful, I suggest sticking with what you wrote ]

Alex

---

From: bert hubert <[email-masked]>
Date: Sat, 17 Nov 2007 14:00:21 +0100

> third party, even if this third party has access to previous wire

I like it a lot.

> introducing a random [RFC 4086] or pseudo-random component into the

This could be put in chapter 10, 'rationale' perhaps.

Thanks!

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 17 Nov 2007 14:01:06 +0100

On Sat, Nov 17, 2007 at 11:56:10AM +0000,
 Alex Bligh <[email-masked]> wrote 
 a message of 28 lines which said:

> I am presuming the "Rationale" section is not for the RFC but for
> the list,

IMHO, no, it should go into the RFC. I'm one of the people who think
that RFCs lack rationales and explanations. Of course, the rationale
must be clearly separated from the normative rules.

> or we might change "bad guys" to "attacker" etc.

OK

---

From: Florian Weimer <[email-masked]>
Date: Sun, 18 Nov 2007 00:45:34 +0100

> introducing a random [RFC 4086] or pseudo-random component into the

Nit: RFC 4086 covers pseudo-randomness as well.  Not very extensively,
but it's there.

> SERVFAIL.

Ah!  Finally a reason for non-repeating IDs.  Thanks.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 18 Nov 2007 14:29:48 +0100

On Sat, Nov 10, 2007 at 07:42:33PM -0200,
 Stephane Bortzmeyer <[email-masked]> wrote 

> mentioned in section 9 all apply.

And about this issue? Everybody agrees?

---

From: bert hubert <[email-masked]>
Date: Sun, 18 Nov 2007 15:20:56 +0100

> And about this issue? Everybody agrees?

I agree, at least.

---

From: Alex Bligh <[email-masked]>
Date: Sun, 18 Nov 2007 14:59:26 +0000

> And about this issue? Everybody agrees?

Yes, though I am not sure the "In addition" bit adds anything. Either it
means it should only listen to answers with the IP source address of those
nameservers (which I am pretty sure is taken care of in the normal rules
for any query originating host unless I am missing something), or it means
they should somehow be able to determine whether the answers /actually/
come from those nameservers and are thus not spoofed (which is not
possible).

Alex

---

From: Danny Mayer <[email-masked]>
Date: Sun, 18 Nov 2007 15:28:16 -0500

> into the mechanism used to select the ID

You can use CryptGenRandom() on Windows if you want a good random number
generator. However, none of this has anything to do with the question on
Query-IDs and is at a level of detail that the implementor would be
dealing with.

Danny

---

From: Shane Kerr <[email-masked]>
Date: Mon, 19 Nov 2007 11:52:38 +0100

> believe this captures the discussion in the WG and that nothing was

Nice. I like it.

- --
Shane