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

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

Olafur,

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

(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

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