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

From: Roy Arends <[email-masked]>
Date: Mon, 23 Jul 2001 12:43:26 -0700

On Mon, 23 Jul 2001, Edward Lewis wrote:

> At 11:14 PM -0400 7/20/01, Roy Arends wrote:
> >Ofcourse this could mean that the data served by an authoritative server
> >is not authenticated at all while the AD is set, but that is the
> >responsibility of the administrator/domain holder.
>
> Gaack, no!
>
> Please don't set the AD bit without locally verifying the data.  I'd rather
> have to have the resolver check for either AA or AD than have the AD bit
> mean something inconsistently.  (1 bit = YES/NO, not = YES/NO/MAYBE.)

The key point here is "don't set the AD bit without locally verifying the
data". Exactly true, no arguments here. BUT, I happen to verify the data
every single day by re-signing the zone. I do not want the extra burdon of
double authentication.

> As far as a the arguement that a stub (non-crypto-doing) resolver would
> always be using a recursive server, I think this is 1) wrong and 2)
> restricive.

What argument. You are not referring to any statements I've made. In the
general case it would be better if a stub (non-crypto-doing) resolver
(lemme rephrase that : ANY resolver !) were using a recursive server,
because it saves bandwith, load on authoritative servers. This is also
true in the cache that someone is doing DNSSEC, regardless of this draft.

The argument is that

1) Don't trust AD, unless TSIG/SIG(0) is used.
2) If you do TSIG/SIG(0) to an authoritative serve you implying you trust
   the authoritative server.
3) If you trust the authoritative server, you don't need the AD bit.

> Why can't the authortitative server be made to optionally "verify on send"
> and thus set the AD bit that way?

Because it does not add extra trust.

> Why do I have to buy into the mantra "I just trust what's on my disk?"

Come'on, this is like saying, "I wanna trust the server, but I don't want
automagically want to trust the data, so the server must validate it". Why
would a malicious user not compromise the server-software, if it could
compromise the data on disk.

If you want to trust an authoritative nameserver, use TSIG/SIG(0), it is
the only real trust mechanism in this particular scheme.

Roy Arends
Nominum

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: Mon, 23 Jul 2001 13:44:00 -0700

>every single day by re-signing the zone. I do not want the extra burdon of

The BIND 9 signer doesn't always verify the signatures it generates.
(There's an option to do so, but the server can't tell if it has been used.)

>What argument. You are not referring to any statements I've made.

You're right - the "argument I referred to was the one Brian raised - that
the answering server should not be an authoritative server.

>                                                                  In the

Don't pin me into having to use the server just one way!  Many folks will
combine the authortitative server with a (local-only) recursive server,
e.g., as on a firewall.

>Because it does not add extra trust.

It's not always about trust.  (See my earlier message about signature
validity and verifying the key chain.)

>the only real trust mechanism in this particular scheme.

Well, there is IPSEC too.  But my point here is that I don't want the
specification to be limited by what is implemented.

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

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 23 Jul 2001 13:44:07 -0700

> > At 11:14 PM -0400 7/20/01, Roy Arends wrote:

There is an extra dimension missing from this arguement, Nameserver trust.
Resolver either trusts a nameserver (by policy) or it does not!

If I configure my resolver to trust noone then it will verify all
signatures. If I configure it to trust cr.yp.to. then it will verify all
signatures execpt the ones that come from cr.yp.to. with the AD bit set.

> 1) Don't trust AD, unless TSIG/SIG(0) is used.

I think you want to say,
Do not trust AD unless message is authenticated AND from a
trusted nameserver. 

Authenticated== TSIG/SIG(0)  (IPsec and TLS might also be allowed)
As for the nameserver I can use authentication to any server but
does that mean I trust them to do everything correctly ?  
Answer: NO. 

>    the authoritative server.

TSIG only authenticates the message and origin, what resolver does 
with the contents depends on policy, it may or may not trust the
server. 

> 3) If you trust the authoritative server, you don't need the AD bit.

Correct, in the case of authorative data from that server, 
For authorative answers (AA set), AD is redundant, but
if AA is not set then AD has value. 

	Olafur

---

From: Jakob Schlyter <[email-masked]>
Date: Mon, 23 Jul 2001 15:33:50 -0700

> if AA is not set then AD has value.

the AD bit is very useful for applications that like to get a hint whether
the data was authenticated (i.e. "secured by dnssec") or not. it is
currently also the only way for an application that doesn't do dnssec on
its own to know if the server verified the data or not.

the application shouldn't have to care about AA - just looking at AD is
enough if we trust the configured server. a system running a local
cache-only nameserver configured to do dnssec verification is one example
where this could be used.

	jakob