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