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

[Alex Bligh <alex@alex.org.uk>]

--On 13 November 2007 11:04:45 -0500 Andrew Sullivan 
<andrew@ca.afilias.info> wrote:

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

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

I wrote:
> 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'.

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

--
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/>