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

From: [email-masked]
Date: Fri, 20 Jul 2001 05:50:13 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title		: Redefinition of DNS AD bit
	Author(s)	: B. Wellington, O. Gudmundsson
	Filename	: draft-ietf-dnsext-ad-is-secure-03.txt
	Pages		: 5
	Date		: 19-Jul-01
	
Based on implementation experience, the current definition of the AD
bit in the DNS header is not useful. This draft changes the
specification so that the AD bit is only set on answers where
signatures have been cryptographically verified.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ad-is-secure-03.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dnsext-ad-is-secure-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsext-ad-is-secure-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Roy Arends <[email-masked]>
Date: Fri, 20 Jul 2001 07:03:47 -0700

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.