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

[Roy Arends <[e-mail]>]

Hello, I would like to see some clarifications on the ***** marked
sections.

Thanks,

Roy
------------------------------------------------------------------------
INTERNET-DRAFT        AD bit set on secure answers             July 2001

2 - Setting of AD bit

   Section 6.1 of RFC2535 says:

   "The AD bit MUST NOT be set on a response unless all of the RRs in
   the answer and authority sections of the response are either
   Authenticated or Insecure."

   The changes are to delete the words "either" and "or Insecure" from
   the sentence.

   The replacement text reads:

   "The AD bit MUST NOT be set on a response unless all of the RRsets in
   the answer and authority sections of the response are Authenticated."

   "The AD bit SHOULD be set if and only if all RRs in the answer
   section and any relevant negative response RRs in that authority
   section are Authenticated."

   AD should be set if and only if all RRs in the answer section, and
   any relevant negative response RRs in the authority section are
   Authenticated.

   The AD bit MUST NOT be set on a response unless all of the RRsets in
   the answer and authority sections are Authenticated.
   A resolver MUST NOT blindly trust the AD bit unless it communicates
   with the server over secure transport mechanism or using message
   authentication such as TSIG[RFC2845] or SIG(0)[RFC2931], and the
   resolver policy is that it can trust the server.

   Any DNS server supporting the OK bit MUST support this definition of
   the AD bit.

*****
OK bit as in DNSSEC OK bit, specified in draft-ietf-dnsext-dnssec-okbit-02.txt
? If this is the case, please refer to it as DO (DNSSEC OK) bit.
*****

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

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

3 - Interpretation of the AD bit

   A response containing data marked Insecure in the answer or authority
   section will never have the AD bit set.  In this case, the resolver
   SHOULD treat the data as Insecure whether or not SIG records are
   present.

4 - Security Considerations:

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



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