[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Protection of unsecured delegations
On Thu, 20 Dec 2001, Bill Sommerfeld wrote:
> I'd be less concerned about the delegation vs. leaf data issue for
> opt-in as long as folks who haven't yet set up fully secured
> delegations can opt for 2535-style null key..
>
> I think there needs to be more text on resolver behavior, and, in
> particular, a discussion of resolver search paths.
>
> I can see resolvers doing any of:
>
> [a] Do the lookup and only return trusted data. Not useful to me
> until everyone I care about has opted in..
>
> [b] If there's trusted data anywhere on the path, return the first
> trusted answer, otherwise return the first non-trusted answer.
>
> [c] Return the first name along the path for which a query returns
> some data.
>
> Version [b] provides much better protection of the innocent than [c].
A secure resolver knows what to expect. It expects a signed statement.
This statement is unambiguous.
so a secure resolver does:
[a] Does the lookup and starts at some secure [super]-domain (it has to
have a key preconfigured right ?)
or
[b] Does the lookup and does not care about security (it has no key
preconfigured for a particular [super]domain).
We're talking about [a] here. The resolver knows if it must expect a
secured domain, since the parent unambiguously states that to the
resolver.
Roy Arends
Nominum
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.