Subject: Re: IESG feedback on dnsext-ad-is-secure

From: Edward Lewis <[email-masked]>
Date: Sat, 15 Jun 2002 23:30:29 -0400

I should report on a meeting[0] of a pair of black helicopters near I-495[1].

Olafur pointed out to me that the purpose (perhaps one of many, but 
this was our discussion) of the AD bit is for applications to see 
that certain processing was performed on the answer.  The AD bit is 
supposed to only be used when the "last hop" was secure, e.g., 
(e.g.!) TSIG-covered.  While I began to feel a little guilty for 
holding this draft up given this discussion, I began to rethink 
recent discussions...

Robert Elz pointed out that the AD bit could be used to determine if 
the resolver is capable of doing DNSSEC (and did DNSSEC).  I can see 
this, but if the AD bit should only be consulted if the back end is 
reached in a trusted manner (TSIG/SIG(0)/or "whatever"), then just 
being able to establish a trusted message exchange should do the 
trick.  I.e., if you went to the trouble to configure a secure 
association with a server, then you trust the server did its best to 
get the answer.

My objection is still based upon the fact that the AD bit can mislead 
a resolver - given the case of bad keys at a trusted server (eg one I 
share a TSIG with).  I don't think the AD bit adds much to the 
protocol[2] - a stub resolver could just tell an application that the 
answer came from a server it trusts.

My intent is to state this misgiving of mine.  If folks think I'm 
just being obstinate, then declare consensus despite my objection. 
It's not like I'll turn in my helicopter keys if the draft "passes."

[0] Attendees: Olafur Gudmundsson (Helicopter call sign DNS Force 
One) and myself (call sing DNS 10738).

Agenda: How he was doing, how his wife is doing, how his kids are, 
and some DNS stuff.  I hope folks forgive me for not covering the 
results of the first 3 agenda discussions.

[1] A cheesy reference to the beltway on the west side of Washington DC.

[2] Maybe if a stub resolver has trust relationships with multiple 
servers, it will want to ask them all until it find an answer with 
the AD bit set.  If folks think defining the AD bit for this case is 
worth it, in spite of what I see as the downside.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Greg Hudson <[email-masked]>
Date: 16 Jun 2002 00:28:40 -0400

On Sat, 2002-06-15 at 23:30, Edward Lewis wrote:
> I.e., if you went to the trouble to configure a secure 

Okay, the server did its best to get the answer.  Now, was the record I
asked for signed, or not?

I'm not sure quite where the misunderstanding is here.  Your criticisms
almost seem to be based on the old RFC2535 definition of the AD bit
(quoting from draft-ad-is-secure):

   As specified in RFC 2535 (section 6.1), the AD bit indicates in a
   response that all data included in the answer and authority sections
   of the response have been authenticated by the server according to
   the policies of that server.  This is not especially useful in
   practice, since a conformant server should never reply with data that
   failed its security policy.

Whereas the new definition would be (again quoting the draft):

   This draft proposes to redefine the AD bit such that it is only set
   if all data in the response has been cryptographically verified or
   otherwise meets the server's local security policy.  Thus, a response
   containing properly delegated insecure data will not have AD set, nor
   will a response from a server configured without DNSSEC keys.  As
   before, data which failed to verify will not be returned.

(Where the "otherwise meets the server's local security policy" is, I
think, only intended to handle exceptional situations, such as when the
recursive resolver is for some reason using out-of-band information to
authenticate the origin of the data.  Or when the data is authoritative,
which is a case that shouldn't matter very often.)

If a recursive resolver has the wrong preconfigured keys, then yes, it
will behave improperly (it will discard good records and potentially
pass on bad records).  The same could happen for a stub resolver which
does its own verification and has the wrong keys.  I'm not sure why this
matters.  The AD bit isn't supposed to mean "I'm a more trustworthy
resolver"; by the new definition, it means "the record you asked for was
signed and checks out okay."

---

From: Edward Lewis <[email-masked]>
Date: Sun, 16 Jun 2002 00:45:57 -0400

>asked for signed, or not?

1) There is no SIG record - no checking, but the server did verify 
that the answer should not be signed.

2) There is a SIG record - the server did check the answer and either 
found that the SIG validated the answer or that the SIG was 
immaterial because the answer didn't require a signature.

Maybe the application wants to distinguish between the two cases.  If 
that case, the application should have the validation done locally.

Perhaps the argument should be that API's need to be able to convey 
whether the validation was done (locally, e.g., by lwresd).  I really 
don't see why the AD bit is in the protocol.

The AD bit isn't something one server gets from another server, each 
server willing to do DNSSEC processing should be setting the CD bit 
on query.  The information in the AD bit matters just to the end 
user, and if the AD bit is important, the work should be done locally 
and the results made available in the API.  But not the protocol.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Ted Lemon <[email-masked]>
Date: Sat, 15 Jun 2002 23:42:52 -0500

I think the point of the AD bit is that the *application* would *do 
something different* with the data depending on whether or not it was set.
    This is similar to the present case with, e.g., Mozilla, where depending 
on your configuration, it may pop up a "Warning, data transmitted is not 
private" box if the connection isn't encrypted - here, it might pop up a 
warning saying "warning: I cannot verify that the address I have for 
www.amazon.com is actually an address at amazon.com, because the DNS record 
wasn't signed."

This is a useful thing, and I'd like it if, in the future, Mozilla would do 
this.   There are two ways for Mozilla to do this.   One is to do the 
signature verification itself.   The other is to trust its resolving name 
server to do it.   Which is better, I will not venture to say, since my own 
opinion on this is divided, but it definitely does not match what you are 
saying:

> My objection is still based upon the fact that the AD bit can mislead a 
> resolver - given the case of bad keys at a trusted server (eg one I share 
> a TSIG with).  I don't think the AD bit adds much to the protocol[2] - a 
> stub resolver could just tell an application that the answer came from a 
> server it trusts.

This isn't what the ad-is-secure draft says the AD bit does.   The 
AD-is-secure draft says the AD bit means the data was definitely signed, 
and either the signature was verified by the resolving name server, or, 
that the resolving name server is authoritative for that data, and thus can 
assert that it is correct.   The draft seems pretty clear on this point.

So "a stub resolver could just tell an application that the answer came 
from a server it trusts" isn't good enough, because the question that the 
AD bit answers is not about the resolving server - it is about the data.   
A trusted server may say to the stub resolver, "here's the data, but I can'
t verify it, so good luck."   It says this by not setting the AD bit.

Does this make any sense to you, or am I making a mistake about this 
somewhere?   I don't understand your point about bad keys, so maybe I'm 
missing something.