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

From: Brian Wellington <[email-masked]>
Date: Wed, 25 Jul 2001 10:00:19 -0700

On Wed, 25 Jul 2001, Edward Lewis wrote:

> The discussion on this document has certainly gotten off course.  I think
> that is a symptom of problems in some of the wording in the document.

I disagree.

> The document says (in section 2):
>
> >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."
>
> The first paragraph contains a double negative.  Although this is a grammer
> problem, many times such occurrances result in misinterpretations.
>
> My more pertinent concern is the referral to "are Authenticated."
>
> One possible interpretation is that the data is authenticated upon entry
> into the server - this is the interpretation held by, at least Brian [0]
> (can't speak for Olafur as I didn't get an indication from his messages).
>
> Another interpretation of this phrase is that data is authenticated upon
> exit from the server.  Other participants in the discussion - Roy, Jakob,
> and I arrived at this interpretation and discussed this at NIST.  Ted's
> viewpoint is also in line with "the gang of three" from earlier
> discussions, he was not at the particular workshop.

In the context of a primary server:

	In the case of a primary server for a secure zone, the data MAY be
	considered Authenticated, depending on local policy.

As far as I can tell, the entire discussion has centered around the
statement.  So, a primary server can set Authenticated based on whatever
criteria it wants.

For a recursive server, it doesn't matter.  If the data is Authenticated
when it's received by the server, the TTL is clamped such that the server
drops it before it should be considered anything but Authenticated.  So,
assuming you trust your clock, it will be Authenticated when handed out.

> So, my suggestion is for the authors to clarity the meaning of "are
> Authenticated" in the temporal sense (and use proper capitalization ;)).  I
> understand that this seems like a silly clarification, but the lack of this
> has resulted in the thread we've witnessed.

I don't a problem here.

Brian

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

---

From: Edward Lewis <[email-masked]>
Date: Thu, 26 Jul 2001 08:11:19 -0700

>I disagree.

Sigh.

Anyway, here is (a start on) how I would clean up the text:

"In an answer in which all RR sets in the answer and authority sections are
cryptographically authenticated according to the responding servers policy,
the AD bit MUST be set to 1 if the query indicates the resolver understands
DNSSEC [ref: DNSSEC OK draft].

[[Note the use of MUST and not SHOULD.]]

"Unless the responder has cryptographically authenticated all of the RR
sets in the answer and authority sections of the response, the AD bit MUST
be set to 0.  Any authentication MUST include authentication of all key
sets used when chaining.  The authentication MAY occur upon receipt of the
data or MAY occur upon reply.

"In an authoritative answer (AA bit is set), with RR sets obtained from a
zone file or zone transfer but not cryptographically authenticated by the
name server, the AD bit MUST be set to 0.

"If the resolver does not indicate knowledge of DNSSEC, the AD bit MUST be
set to 0."

A table to summarize AD bit settings:
Server:             from disk no check verify/get verify/put fail verification
                    --------- -------- ---------- ---------- -----------------
Resolver:
doesn't know DNSSEC     0         0        0           0      0 serv fail
knows DNSSEC            0         0        1           1      0 serv fail

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.