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

Edward Lewis <lewis@tislabs.com> Sun, 29 July 2001 05:52 UTC

Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA13979 for <dnsext-archive@lists.ietf.org>; Sun, 29 Jul 2001 01:52:31 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.31 #1) id 15QWPH-000CkC-00 for namedroppers-data@psg.com; Sat, 28 Jul 2001 08:53:35 -0700
Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15QWPH-000Ck6-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 08:53:35 -0700
Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15QWPH-000Nwk-00 for namedroppers@ops.ietf.org; Sat, 28 Jul 2001 08:53:35 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
From: Edward Lewis <lewis@tislabs.com>
To: Brian Wellington <Brian.Wellington@nominum.com>
Cc: Edward Lewis <lewis@tislabs.com>, ogud@ogud.com, DNSEXT <namedroppers@ops.ietf.org>
Subject: Re: restart: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt
In-Reply-To: <Pine.LNX.4.33.0107271052430.18905-100000@spratly.nominum.com>
References: <v03130310b7875228d38b@[10.33.10.175]>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Message-Id: <E15QWPH-000CkC-00@psg.com>
Date: Sat, 28 Jul 2001 08:53:35 -0700
Content-Transfer-Encoding: 7bit

At 2:07 PM -0400 7/27/01, Brian Wellington wrote:

Finally - I can see the motivation.  "Intents," or requirements, should
appear in the introduction to set the context for the document.

>And all I want is the ability to run an authoritative server without
>crypto that can set the AD bit to 1 on data that is secure.

I don't think this should be permitted.  Why is it so important to have the
AD bit set to 1 if the answering server does not bother with cryptography?

The AA bit and AD bit exist on different planes of the DNS protocol.  (This
is a bit abstract.)  AA rests on the name server plane, and is
topology-based.  The AA bit indicates that there is no better place to get
an answer than this.  AD rests on the zone data plan, it relates to the
end-to-end security of data from its zone to the resolver.  The AD bit
indicates that the responder has checked the data it has received and is
now forwarding on.

IMHO an AA bit outranks an AD bit.  Data with AA=1,AD=0 is reputedly coming
from *the* source (TSIG, et.al.)  Data with AA=0,AD=1 is reputedly data
that some intermediary has verified as coming from the source.  I would
assign higher credibility to AA=1,AD=0 than AA=0,AD=1.

If both AA=1 ,and AD=1, then the data is coming from a rather conservative
source.  (Which some applications may demand.)  If the setting of AD=1 is
allowed without doing crypto, some information is lost (specifically, how
conservative is the source).

(Perhaps we could Jakob to comment on this.)

>The intention was basically to stop:
>  - recursive servers from setting the AD bit on provably insecure data.
>  - authoritative servers from setting the AD bit on unsecured zones.

I think that this effort isn't strong enough then.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: lewis@tislabs.com

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

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




to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.