Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt

[Roy Arends <[e-mail]>]

On Fri, 20 Jul 2001, Brian Wellington wrote:

> On Fri, 20 Jul 2001, Roy Arends wrote:
>
> > Ah, so without cryptographicly authenticating the data which is read
> > from disk, the primary could set the AD bit on responses since it may
> > consider locally configured data to be in authenticated state.
> >
> > I totally object to this.
> >
> > I also do not see a reason for this.
>
> This discussion has already been had several times.

I am aware of that.

> If you don't trust the on-disk zone data, why would you trust anything
> else about the server? A key configured into named.conf could be
> maliciously or accidentally changed in the same way as the master
> file.  The data could expire at some point after the server was
> loaded, and the server would still give out bad data.  In short,
> verifying data on load has no positive effects, and has the huge
> negative effect that it exponentially increases server load time.

So why not authenticate data on query. That solves the server load
problem. Next to that, drop the data (or at least the AD indication) if
the sig is expired.

> Treating on-disk signed data as "Authenticated"  is reasonable behavior,
> and a server may choose to implement this policy.

This is not acceptable to me. Authenticated data is simply authenticated
data, regardless where it comes from. Don't set the AD bit if the data is
not authenticated.

> > > >    Secondary servers SHOULD NOT consider data Authenticated unless the
> > > >    zone was transfered securely or the data was verified.
> > > >
> > > > *****
> > > > or ? So if the zone was transferred securely, the secondary can consider
> > > > the data Authenticated (and thus, set the AD bit) when it actually did not
> > > > verify the contents of the zone ? I don't like it.
> > > > *****
> > >
> > > If the zone is transferred securely, then the secondary is guaranteed to
> > > have the same data as the primary.  The primary is allowed to set AD
> > > without verifying the data also.
> >
> > I totally object to this !
> >
> > TSIG/SIG(0) can transfer a zone securely, even if the data at the
> > primary is corrupt.
> >
> > Only when a server (caching or authoritative) has cryptographicly verified
> > (according to the local policy) the contents of the answer and authority
> > section in a response its about to give out, the AD bit may be set.
> >
> > IMHO local policy MUST NOT include setting AD bit while the contents are
> > actually not cryptographicly verified.
>
> Again, this is not true.  You agree that a secure transfer guarantees that
> the secondary has the same data as the primary, so if the primary trusts
> it, the secondary should also.

I agree on the part that the secondary will have the same data as the
primary, when securely transferred. But still, the data may be corrupt.

TSIG/SIG(0) authenticates resolvers, servers, and will preserve data
integrity during transport. Thats it. The data itself may be totally
corrupt. DNSSEC is used for origin authentication, and the AD should
reflect that. Origin as in Domain, not Server.

Regards,

Roy Arends
Nominum



to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.