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

[Stephane Bortzmeyer <bortzmeyer@nic.fr>]

On Mon, Nov 12, 2007 at 08:35:43PM -0200,
 Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote 
 a message of 25 lines which said:

> 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'.


--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>