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

[Brian Wellington <[e-mail]>]

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

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

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

> > >    This document redefines a bit in the DNS header.  If a resolver
> > >    trusts the value of the AD bit, it must be sure that the server is
> > >    using the updated definition, which is any server supporting the OK
> > >    bit.
> > >
> > > *****
> > > What are the implictions for the AD bit when the CD bit is set in a query.
> > > MAY/SHOULD[NOT]/MUST[NOT] a response have the AD bit set when CD (and
> > > optionally DO) bit is set ? The resolver is probably not interested in AD
> > > bit when CD bit is set, but a clarification would be good.
> > > *****
> >
> > There are no implications.  Whether the AD bit is on in a response
> > reflects the security status of data, not whether CD was set in the query.
> > Even if CD is set, the response can have AD set if the data had already
> > been verified.
>
> I agree totally, but IMHO it would be good if this independence of CD (and
> DO) is documented.

The lack of mention of CD seems to implicitly indicate this, but I don't
care too much if more text is added.

Brian



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