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

From: Olafur Gudmundsson <[email-masked]>
Date: Sat, 04 Aug 2001 01:00:07 -0700

At 09:17 AM 7/30/2001, Jakob Schlyter wrote:
>On Sun, 29 Jul 2001, Brian Wellington wrote:

As Brian's co-author I agree with most of what he as said.
Given that I'm the co-chair of the working group I have not been
jumping into this argument.
But I think it is time to put my foot down.

As far as I can tell there are two religious camps arguing here and
as in any good theological argument there is no way for one to agree
with the other ;-)
And of course the argument is over a real fine point.

The two arguments are:
#1 Server can set the AD bit on SECURE AUTHORATIVE data in accordance local
policy, all other data must be cryptographically verified before setting
the AD bit.

#2 Server can ONLY set the AD bit after cryptographically verifying
signatures.

If we follow the second policy then server needs to verify all
authoritative data before including it in answer, this implies either
verify-on-load or verify-on-answer.

Now lets think about this in a different way,
if the secure zone cryptographic checksum (similar to SIG(0) or TSIG).
on the master file is verifying that checksum acceptable under policy #2?
Under strict interpretation the answer is NO, but the data is just
as secure as if all the signatures are verified.

Also who trusts the AD bit ?
Only resolvers that are pre configured to trust a particular server
will accept the AD bit, ALL OTHERS MUST ignore it.

Someone should write a BCP on when it is ok to set the AD bit on
secure authoritative data.

> > This is the problem.  The stub resolver should not care whether the
> > server has validated the data or not.  If the resolver trusts the
> > server, the server trusts the data, and the communication is secure,
> > the resolver should trust the data.
>
>the stub resolver may care whether the server has validated the data or
>not. if the servers hasn't validated the data, e.g. data data was never
>protected by dnssec, it can choose not to trust it at all.

Ok, now we are in hair splinting mode, IMHO if client trusts server
it must accept the whole policy of the server.
If that is unacceptable I think the way to solve this is to add EDNS
options that request specific services from the server, such as
"VERIFY ALL data before setting AD".
That should satisfy your desire, and allows the server to tell you
if it is not willing by returning REFUSED.

         Olafur

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

---

From: Bill Sommerfeld <[email-masked]>
Date: Sun, 05 Aug 2001 09:07:22 -0700

> verify-on-load or verify-on-answer.

There's also verify-and-cache-on-first-answer ..

					- Bill

---

From: Edward Lewis <[email-masked]>
Date: Mon, 06 Aug 2001 05:07:49 -0700

>And of course the argument is over a real fine point.

And the setting of one bit.

>verify-on-load or verify-on-answer.

Not true - the server could just return AA=1, AD=0.

>as secure as if all the signatures are verified.

What, you mean SIG(AXFR)?

I would say no - the AD means that the cryptograhic chain was checked back
to some point, a la RFC 300[78].  IMHO, if we don't specify a particular
way of doing this, there will be too many possible interpretations.

>will accept the AD bit, ALL OTHERS MUST ignore it.

Not true.  If I want to view a web page and only care that the address is
reasonably right (ie, I'm just view an cartoon for entertainment), I may be
willing to trust the server local to me, that I have reached via IPsec, or
behind a firewall.  This is a case where I may value the setting of the AD
bit without knowing the policy of the server, just that I have faith that
the provider of the moment is sane.

>secure authoritative data.

Isn't this what your document is about?

>it must accept the whole policy of the server.

The issue of "trust" isn't the problem - its the setting of the bit.  Let's
define what the bit means and worry about how resolvers and client
applications interpret it later.  (Applications will have different
requirements, there's no interoperability issue when we are talking about
the interpretation of a bit within an application.)

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