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:
>
> > Hello, I would like to see some clarifications on the ***** marked
> > sections.
>
> >                A DNS server following this modified specification will
> >    only set the AD bit when it has cryptographically verified the data
> >    in the answer. In the case of a primary server for a secure zone,
> >    the data MAY be considered Authenticated, depending on local policy.
> >
> > *****
> > I don't know how to read this.
> >
> > In the case of a primary server for a secure zone, the data MAY be
> > considered Authenticated, depending on local policy, when what ?
> > When the AD bit is set ? May it set the AD bit if it is the primary server
> > for a secure zone, though the zone is actually not authenticated by the
> > server ? The last sentence of the above section is a bit confusing.
> > *****
>
> "Authenticated" is a term defined in RFC 2535, section 6.  It is normally
> used when referring to the security status of data on a recursive server.
> This particular text says that the server may consider locally configured
> data to be in the "Authenticated" state.

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.

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

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

Regards

Roy



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