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

From: [email-masked] (Ted Lindgreen)
Date: Wed, 25 Jul 2001 06:26:58 -0700

[Quoting "David R. Conrad", on Jul 25,  2:22, in "Re: I-D ACTION:draft ..."]
> Hmmm.
> 
> I thought this list was not supposed to delve into particular implementations.

You are right, and I'm sorry.

> Discussions about what ISC's plans are (or intents were) with BIND are 
> probably more appropriate on bind{,9}-{users,[email-masked] or with ISC's 
> board directly.  While I am not able to speak for ISC in any way,  I 
> suspect ISC will do whatever people who fund it want it to do.  I also 
> suspect that ISC would be willing to consider donations of code for 
> functionality that people wish to have implemented including something like 
> verify-on-send/reply or whatever (particularly if it is configurable to 
> "off" by the administrator who actually wants his/her nameserver to do 
> something other than verify data).

Yes, that's what I expected to hear. Actually, we are trying to make
extentions on "host" and "dig", like it was available in Bind-8, to
perform SIG verification. However, e-mail exchange with  Brian made
clear, that such extentions are not desired and will definately not
ever be included in BIND-9.

So, I'm a bit confused, again. We, NLnet Labs, think that SIG
verification tools should be a necessary part of BIND.

-- ted

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

---

From: Paul A Vixie <[email-masked]>
Date: Wed, 25 Jul 2001 08:23:31 -0700

> verification tools should be a necessary part of BIND.

if it's clean code and includes changes to the documentation and is an
option that defaults to off and there are no restrictive licenses on it,
isc would include it in a subsequent release.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 25 Jul 2001 08:04:58 -0700

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.

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.

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.

[0] Not naming names to lay blame, just to clarify that my comment applies
to one of the two document authors.

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