Subject: Question regarding the AD bit according to RFC2535.

From: Roy Arends <[email-masked]>
Date: Mon, 3 Apr 2000 20:32:16 +0200 (CEST)

Hello,

I've a little trouble understanding the value of the AD bit in a response.

According to RFC2535:

1. In section 6.1 it states: 
   "The AD (authentic data) bit indicates in a response that all the data
    included in the answer and authority portion of the response has been
    authenticated by the server according to the policies of that server."

The definition of authenticated data:

2. In section 6. it states:
   "Authenticated means that the data has a valid SIG under a KEY 
    traceable via a chain of zero or more SIG and KEY RRs allowed by the
    resolvers policies to a KEY staticly configured at the resolver."

But is seems to contradict with the following statement in:

3. In section 6.1 last paragraph:
   "For non-security aware resolvers or security aware resolvers
    requesting service by having the CD bit clear, security aware servers
    MUST return only Authenticated or Insecure data in the answer and
    authority sections with the AD bit set in the response."

And also with the statement in:

4. Appendix B: part 9:
   "The AD bit only indicates that the answer and authority sections of
    the response are authoritative."

In short:

1 and 2 looks like the AD bit is indicating that the returned data is
cryptographically checked.

3 and 4 looks like the AD bit is indicating that the returned data is
either cryptographically secure or is data from an insecure zone.

Can anyone clearify this matter ?

TIA, regards,

Roy Arends
-- 
[email-masked]                NLnet Labs
tel +31208884551                Kruislaan 419
|\ ||   _  _|_  |   _ |_  _     1098 VA  Amsterdam
| \||__| )(-|_  |__(_||_)_)     The Netherlands

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

---

From: Roy Arends <[email-masked]>
Date: Tue, 4 Apr 2000 14:06:40 +0200 (CEST)

On Tue, 4 Apr 2000, Edward Lewis wrote:

> At 2:32 PM -0400 4/3/00, Roy Arends wrote:
> IMHO, the intent is the latter.  (Lemme, check first, the set of data
> meeting the first criterion is a subset of the set of data meeting the
> second, right?)

Right. Thanks for clearing this up.

> That being said, there has been further discussion on the meaning of the AD
> bit.    Some implementers have been questioning having it include data in
> the additional sections, e.g., glue data.
> 
> It is possible that the definition of the AD bit could represent an
> amplification tool for denial of service attacks.  By having arbitrarily
> long additional sections, an attacker could have a secure resolver spend
> CPU cycles verifying unrelated data just to achieve the AD setting.  This
> may not be true, but it has come up in discussions.

The additional records section contains RRs which relate to the query, but
are not strictly answers for the question. Having them verified is extra
work that might not be neccesary. OTOH, not verifing it might result in
another query for data previously in the additional section, and now this
data has to be checked alltogether, which is more demanding (ergo larger
DOS potential) then the first.

Thanks, regards,

Roy.

> PS - I thought the WG had determined that there would be an AD-bit
> clarification draft in the future, to summarize these ideas and propose a
> (potentially) safer meaning to the bit.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 4 Apr 2000 07:07:31 -0400

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

"Trying is the first step to failure." - Homer Simpson
"No! Try not. Do... or do not. There is no try." - Yoda
"It takes years of training to know when to do nothing" - Dogbert 1/21/00

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

---

From: Roy Arends <[email-masked]>
Date: Tue, 4 Apr 2000 18:37:18 +0200 (CEST)

On Tue, 4 Apr 2000, Donald E. Eastlake 3rd wrote:

> Hi,

[cut]

> That was the intent, where "insecure" is defined from the point of
> view of that server and depends on what keys it has staticly
> configured, what algorithms it implements, etc.
> 
> Hope this is helpful,
> Donald

Very helpful. 

Thanks, regards,

Roy.

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Tue, 04 Apr 2000 12:16:20 -0400

Hi,

From:  Roy Arends <[email-masked]>
Date:  Mon, 3 Apr 2000 20:32:16 +0200 (CEST)
To:  DNSEXT WG Mailing list <[email-masked]>
Message-ID:  <[email-masked]>

>    authenticated by the server according to the policies of that server."

The intent was to mean that the data had passed all the checks the
server was going to impose.  This includes data that can not be
cryptographically verified because it is in an unsigned zone or a zone
such that the server does not have a key for that zone, or an
ancestor, staticly configured etc...  Note that it specifies the
answer and authority portions so, by impliation, the AD bit was
intended to say nothing about the additional information section.

>    resolvers policies to a KEY staticly configured at the resolver."

The use of the word "Authenenticated" in the above qutoed sentence was
in reference to the data statuses of Authenticated, Pending, Insecure,
and Bad defined in Section 6.  This usage is confusing.  Perhpas it
would have been better if this special usage of Authenticated were
replaced by "Cryptographically Verified".

>    authority sections with the AD bit set in the response."

The above quoted sentence correctly describes the intent.

>    the response are authoritative."

Appendix B is the list of changes from the previous version.  The use
of the word "authoritative" in the above quoted sentence is confusing
because of the special meaning of "authoritative" in the DNS.  This
sentence is just pointing out that the additional information section
isn't covered by the AD bit, something which RFC 2535 tries to
clarify.  The full section is:

   9. It was clarified that the presence of the AD bit in a response
      does not apply to the additional information section or to glue
      address or delegation point NS RRs.  The AD bit only indicates
      that the answer and authority sections of the response are
      authoritative.

>cryptographically checked.

The intent was to indicate that the data has passed whatever checks
the server cares to impose, which should be cryptographic where
possible, but can not in zones that are insecure from that server's
point of view.

>Can anyone clearify this matter ?

Hope this is helpful,
Donald
===================================================================
 Donald E. Eastlake 3rd                    [email-masked]
 65 Shindegan Hill Rd, RR#1                 [email-masked]
 Carmel, NY 10512 USA     +1 914-276-2668(h)    +1 508-261-5434(w)