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

From: Erik Nordmark <[email-masked]>
Date: Mon, 10 Jun 2002 15:54:22 +0200 (CEST)

Folks,

The IESG reviewed draft-ietf-dnsext-ad-is-secure-05.txt and has
some significant concerns. While the document just tries to make
the definition of the AD bit more clear and perhaps more useful than it
is today, the document raises the issue of having stub resolvers place
blind trust on a (recursive) resolver. To the extent that the document
implicitly or explicitly encourages this, it isn't clear that 
the document is a good idea.

The document doesn't explain the expected usage of the AD bit
by the receiver. This makes it hard to evaluate the benefits.
Is the intent that the application be notified? If so, what are some
examples of what the application will do based on the value of the bit?

The applicability of the document isn't clear. If the document is
going to move forward it would need a "safe" applicability statement.
For example, while the blind trust in a resolver might make sense e.g. in
an enterprise network, it doesn't seem to make sense in the home/ISP
setting where the ISP would run the resolver.

The document is not in synch with the dns-threats I-D, which
says:
   It is difficult to escape the conclusion that a properly paranoid
   resolver must always perform its own signature checking, and that
   this rule even applies to stub resolvers.

That brings us to the motivation for delegating signature verification
to some other entity. Is there an argument that stub resolver signature 
checking is too expensive? Are there numbers to back this up?
Or is there a problem that one can't easily get stub resolver to verify
all the signatures while using a recursive resolver to do the recursion?
Thus, apart from the fact that the RFC 2535 definition isn't useful
as it stands, what problem are we trying to solve by making the
definition more useful?

Smaller issues
--------------

The document doesn't say what "AD" stands for. It makes sense making this
clear early on (e.g. in the abstract and/or introduction).

In section 2 it isn't clear what is the old vs. new behavior.
For example, I think section 2.0 is unchanged behavior, but it could be 
new behavior. Is section 2.2 unmodified or new behavior?

The abstract says "current behavior" which is a bit odd since
the document redefines the current behavior. Assuming the
AD bit semantics are defined in RFC 2535, it would make sense
to instead say "the definition of the Authentic Data (AD) bit in RFC 2535 ...".
 The final paragraph of the Security Considerations is written
in a way that obscures meaning, in contrast to the related
final paragraph of Section 3.

> Resolvers (full or stub) that blindly trust the AD bit without
>    knowing the security policy of the server generating the answer can
>    not be considered security aware.

It isn't clear what "security aware" means here and that using
that undefined term adds any clarity.

I think the point is that the blind trust in the AD bit MUST
only be used in an environment in which configuration somehow ensures
that the security policy of the server is appropriate.
Thus it doesn't make sense to use this, even is a secure channel
with TSIG or SIG(0) is used, when the client might not trust the
recursive resolver, or it doesn't trust how it discovered the
IP address of the recursive resolver. (e.g. using DHCP).

Please split the references into normative and non-normative per 
the rfc-editor's instructions.

Nits
----

>   application running on a host that has trust relationship with the

s/has/has a/

   The presence of the CD (checking disabled) bit in a query does not
   affect the setting of the AD bit in the response.  If the CD bit is
   set, the server will not perform checking, but SHOULD still set the
   AD bit if the data has already been checked or complies with local
   policy.  The AD bit MUST only be set if DNSSEC records have been
   requested [RFC3225] and relevant SIG records are returned.

wouldn't hurt to better define "checked". I assume this means crypto
sigs verified, or server is authoritative.

   This document redefines a bit in the DNS header.  If a resolver
   trusts the value of the AD bit, it must be sure that the server is
   using the updated definition, which is any server supporting the OK
   bit.

reference to OK bit?

---

--
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: 10 Jun 2002 11:25:28 -0400

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

Speaking as the author of a little-used stub resolver:

> all the signatures while using a recursive resolver to do the recursion?

As I understand it, verifying signatures often requires going and
fetching signature records which were not included in the original
response, possibly due to packet size issues.  One of the whole points
of the stub/recursive resolver separation is to allow applications to
perform DNS resolution using a single request/response pair, and let
some separate big ugly program (as opposed to a library linked against
the applications) handle the consolidation.

We have a limited number of options here:

  1. AD-is-secure

  2. Mandate that recursive resolvers include all necessary signatures
in their replies to the stub resolver.

  3. Destroy, at least partially, the notion of a stub resolver, forcing
applications to link in complicated multi-request resolvers in order to
know the security status of domains.

Option 2 might be better, but it would probably require a TCP fallback
for domains with more than about (guessing here) six zone delegations.

(Incidentally, what's with the blind request for quantitative data?  An
argument may or may not require quantitative data to be sound; it is not
necessarily any more sound if it has that need and the need has been
fulfilled.)

> examples of what the application will do based on the value of the bit?

Most of the time, you probably don't care; it is enough to know that if
the domain was signed, then an attacker would have had a difficult time
trying to spoof it.  But sometimes an application might like to know. 
Examples:

  * A web browser might want to communicate to a user whether the page
they went to had a signed domain name, just as it currently communicates
whether the web page used SSL.

  * If we put application public keys into DNS as has been
(controversially) suggested in the past, then an unsigned key would need
to be ignored or red-flagged to the user.

  * If the Mail-Transmitter RR goes forward, then an MTA might want to
note whether MT RR it looked up was signed; people might (at least some
day) want to score down mail which wasn't authorized by a signed MT RR.

Since the AD-is-secure draft just defines infrastructure, I wouldn't
really expect it to document the possible uses of that infrastructure.

> While the document just tries to make

There is one common case where that trust is perfectly justified: the
recursive resolver runs on the same machine as the application.

There are certainly common cases where that trust would not be justified
(either the recursive resolver is run by horrible people, or the
communication path to it is easily compromised).

If I were writing a stub resolver using AD-is-secure to communicate the
signedness of a domain, I would probably only report that the domain is
signed if:

  * The AD bit is set on the reply, and
  * The reply came from 127.0.0.1, or
  * The server is explicitly marked as trusted in resolv.conf, and
  * TSIG was used to secure the communication channel, or
  * The TSIG requirement was explicitly overridden in resolv.conf.
    (Because the administer chooses to rely on firewall security, for
    instance.)

That certainly leaves the system open to misconfiguration, but it would
have to be quite explicit.

>    this rule even applies to stub resolvers.

This is kind of an ambiguous statement (what's a "proper irrational fear
that everyone is out to get you"?), but as you're interpreting it, I
don't really agree with it.  If AD-is-secure goes forward, then perhaps
it should be weakened to merely say that performing your own signature
checking is the best way to prevent spoofing and to determine the
signedness of a record.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Jun 2002 09:27:52 +0200 (CEST)

> know the security status of domains.

I don't think those are all the options. As far as I can tell stub resolvers
can place blind trust on the recursive resolver (including the
recursive resolver's decisions to what unsigned information it accepts through)
without requiring any single-bit indication from the recursive resolver. So
putting the question whether "stub resolvers place blind trust on the 
recursive resolver" is a good thing or not, there is the question what the
AD-bit would be useful for in the client - would applications somehow use it?
Do applications today have an API by which they get "security status" from a
local, full DNSsec resolver? How do applications use that information?
Does such local information consist of just one bit? Or the ability to discover
more information about the "security status" of the response?

> for domains with more than about (guessing here) six zone delegations.

This is part of what folks want to understand better since presumbly
there is utility in using recursive resolvers (such as less packets
sent by the client etc) in the cases when
blind trust in a recursive resolver isn't appropriate.

> whether the web page used SSL.

Any indication that there is interest in adding such things to such 
applications? Or is this speculation?

> to be ignored or red-flagged to the user.

I hope that isn't the strongest motivation for this draft.

> really expect it to document the possible uses of that infrastructure.

But it's very hard to evaluate something like this without any understanding
what so ever for what it will be used...
And I think folks are concerned because this specification might have
the side-effect of silently endorsing blind trust in recursive resolvers
even where such trust isn't appropriate. (Should a home user with
a recursive resolver run by their service provider place blind trust in it?
Perhaps it is only appropriate inside coorporations with an IT department which
sets and enforces policies including security policies.)

> recursive resolver runs on the same machine as the application.

But in that case, isn't this an API question more than a protocol question?
I could speculate that in this case a richer interface might make sense
(e.g. not only indicate that it was signed but that it used the manually
configured key for the example.com zone since the whole path from the root
isn't signed; indicate whether the zone uses opt-in or not; indicate that
the signature lifetime has expired but it is deemed ok in spite of this).

   Erik

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 11 Jun 2002 11:20:04 +0200 (MEST)

On Tue, 11 Jun 2002, Erik Nordmark wrote:

> Do applications today have an API by which they get "security status"
> from a local, full DNSsec resolver?

yes, using getrrsetbyname(3): "The RRSET_VALIDATED flag in rri_flags is
set if the AD (autenticated data) bit in the DNS answer is set. This flag
should not be trusted unless the transport between the nameserver and the
resolver is secure (e.g. IPsec, trusted network, loopback communication)."

> How do applications use that information?

the applications we have written use this information to put additional
trust into certificates validated by a local resolver.

> Does such local information consist of just one bit? Or the ability to
> discover more information about the "security status" of the response?

it is currently one bit only since it is only based on ad. more
information would be useful, but one bit is a huge step compared to
nothing.

	jakob

---

From: Paul Vixie <[email-masked]>
Date: Tue, 11 Jun 2002 06:31:40 -0700

stub resolvers already have blind trust in their recursive servers.
(dnssec signature verification at the stub level makes no sense.)

this is what tsig is for.

let's look for a new problem.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Jun 2002 17:44:03 +0200 (CEST)

> (dnssec signature verification at the stub level makes no sense.)

I don't understand why it would never make sense.

Suppose I there is a CPU powerful client with a relatively high round-trip 
time to everywhere (many wireless things have high rtt due to coding
necessary to deal with fast fading radio issues).

Having that client do a single DNS query to a recursive resolver
makes a lot of sense. But coupling this by design with blind trust
in the resolver seems odd to me; having the option for the client
to receive all information necessary to verify the response (as part of
the response from the recursive resolver - yes, there are likely to be
packet size issues - EDNS to the rescue?) seems to make sense when
blind trust isn't appropriate.

   Erik

---

From: Paul Vixie <[email-masked]>
Date: Tue, 11 Jun 2002 08:49:27 -0700

> I don't understand why it would never make sense.

because it will take a huge amount of bandwidth on every query.
as in, several kilobytes of traffic to fully verify an A RR 
before your browser will follow a link.

"stub" means no cache.

---

From: Rob Austein <[email-masked]>
Date: Tue, 11 Jun 2002 12:18:57 -0400

> "stub" means no cache.

A resolver which only issues queries with RD=1 may still have a cache.

I don't care whether one calls such a thing a "stub resolver" or not.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 12 Jun 2002 11:59:56 +0859 ()

Erik;

> makes a lot of sense.

First, that is an issue addressed by additonal RRs.

Second, non-stub resolver may ask recursive service.

Third, rtt of most, if not all, wireless things, including those used
for highly interactive service of telephony and plain WLAN, is low.

						Masataka Ohta

---

From: Greg Hudson <[email-masked]>
Date: 11 Jun 2002 13:30:35 -0400

I am not personally aware of applications which want to know the
signedness of a DNS record, but it does seem like a reasonable thing to
want.  I'll leave it up to others (like the draft authors) to provide
more concrete details.

> But in that case, isn't this an API question more than a protocol question?

Uh, just because the recursive resolver is running on the same machine
doesn't mean that the application is magically using some rich, RPC-like
interface to talk to it.  The stub resolver still communicates with the
recursive resolver using the DNS protocol, just as if it were on a
different host.

So it's still a protocol question.

> I could speculate that in this case a richer interface might make sense

Possibly, but it would be a lot of work to design this richer interface,
no one has a proposal on the table, and AD-is-secure does not damage our
ability to achieve a richer interface in the future.

---

From: Robert Elz <[email-masked]>
Date: Wed, 12 Jun 2002 13:37:23 +0700

Date:        Tue, 11 Jun 2002 12:18:57 -0400
    From:        Rob Austein <[email-masked]>
    Message-ID:  <[email-masked]>

  | A resolver which only issues queries with RD=1 may still have a cache.

Of course, and this is part of the issue here.

  | I don't care whether one calls such a thing a "stub resolver" or not.

But for the purposes of this discussion, resolvers that have no cache are
what is relevant.   It is useful to have a name for such things, and "stub
resolver" seems to be that.

Other resolvers that issue RD=1 queries (there was a time, probably still
is, when all resolvers issued RD=1 always - the only question was whether
the server had RA=1 and would process the recursion) certainly exist,
but are less relevant.

It seems likely that a stub resolver (as defined 2 paragraphs ago) would
like to know whether or not its (presumably trusted) back end has validated
signatures or not.   Since the back end has no way of knowing whether or
not the stub resolver only wants validated answers, it can't just not
reply if the signature checks fail.   Hence the AD bit seems to be useful.

Now for resolvers that want to check signatures themselves, the AD bit
can simply be ignored.   Having it there, either set or clear, cannot
possibly prevent the SIGS being fetched, and validated.

So, all this discussion seems to me to be pretty pointless.   I am pretty
sure the draft already says that the AD bit shouldn't be trusted unless
the resolver receiving it has some other way of trusting the resolver that
sent it.

Note that the back end resolver (the one that received Rd=1, has RA=1, and
actually sets the AD bit) has no method to know what kind of resolver is
talking to it - it doesn't know whether the back end trusts it or not
(it may know that it is going to use TSIG to communicate with its client,
but presence of TSIG does not guarantee trust, nor does its absence
prohibit it), so it just sets the AD bit (or doesn't) on all queries it
processes, regardless of whether the value will end up being used or not.

While space in DNS packets is limited, I thing we can afford that one bit...

kre

---

From: Greg Hudson <[email-masked]>
Date: 12 Jun 2002 10:45:46 -0400

On Wed, 2002-06-12 at 02:37, Robert Elz wrote:
> signatures or not.

Uh, I'm not quite sure what you're saying here, but this statement makes
me a little nervous.  AD=1 means the back end has validated signatures,
*and* all the required signatures were present and valid.  AD=0 means
the back end has not validated signatures, *or* the required signatures
were absent or invalid.  AD doesn't give you a way to determine if the
back end is DNSSEC-aware or not, unless you happen to know of a record
with a valid signature.

It's important that everyone be on the same page here, so that we don't
get AD-is-confused.  People (including area directors) in the opt-in
discussion have already raised the possibility that a query for an
unsigned record in an opt-in zone might come back with the AD bit set,
which could only happen with a completely different meaning for the AD
bit.  Sure, you can cryptographically determine that the requested
record wouldn't be signed if it does exist, but the record clearly fails
the test:

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

---

From: Robert Elz <[email-masked]>
Date: Wed, 12 Jun 2002 22:13:57 +0700

Date:        12 Jun 2002 10:45:46 -0400
    From:        Greg Hudson <[email-masked]>
    Message-ID:  <[email-masked]>

  | Uh, I'm not quite sure what you're saying here,

Most likely I wasn't being very clear, but I disagree with nothing
that you said, so I don't think we have any problem...

My point was more along the lines that receiving a reply with AD=1
set does not commit the recipient to trust the thing - it can go and
do its own validation if it feels the need.

kre

---

From: Rob Austein <[email-masked]>
Date: Wed, 12 Jun 2002 13:01:11 -0400

At Wed, 12 Jun 2002 13:37:23 +0700, Robert Elz wrote:
> what is relevant.

Sorry, but I don't agree that only resolvers with no cache are
relevant.  A resolver for a PDA might include both a small cache and
DNSSEC signature verification code but still be recursive-mode-only,
simply because the iterative resolver function is something that
really doesn't need to be on the PDA if it's readily available from
the environment du jour.  Farming out signature verification to the
environment du jour is a very different proposition.

I'm not saying that there won't be dumb little boxes that support
neither iterative resolution nor signature verification (there almost
certainly will).  I am saying, however, that if I were writing code
for a device with constrained resources, I'd put signature
verification much higher on my priority list than iterative
resolution, particularly since the bulkiest part of the signature
verification code is likely to be crypto functions that I might well
have loaded anyway to support IPsec, TLS, or something like that.

---

From: Robert Elz <[email-masked]>
Date: Thu, 13 Jun 2002 17:12:14 +0700

Date:        Wed, 12 Jun 2002 13:01:11 -0400
    From:        Rob Austein <[email-masked]>
    Message-ID:  <[email-masked]>

  | I'm not saying that there won't be dumb little boxes that support
  | neither iterative resolution nor signature verification (there almost
  | certainly will).

But surely these are the boxes for which the AD bit is relevant?
Your (slightly) smarter boxes can just ignore the bit, however it
is set, can't they?   How can the state of this one bit possibly
alter how your smarter resolver works, assuming it isn't interested
in the information provided (however little or much that may be) ?

kre

---

From: Edward Lewis <[email-masked]>
Date: Thu, 13 Jun 2002 07:53:32 -0400

>But surely these are the boxes for which the AD bit is relevant?

I've objected strongly to this draft for some time now.  There is no 
new content here that hasn't already been presented to the AD, 
chairs, and authors during the last call.

My reasons boil down to:

1) Name servers are already instructed to return only valid answers 
(unless the CD bit was set on query).  Absent TSIG/SIG(0), if the 
resolver is going to trust an unprotected bit (the AD is in the 
header), the resolver might as well trust the operation of the 
protocol.  (I.e., what does the bit add?)

2) The bit is defined to indicate if the answers were checked in 
accordance to the name server's local policy (e.g., the trusted keys 
used, who it feels is authorized to sign the data).  As there is no 
means in the protocol to ask a name server what it's policy is (nor 
even what trusted key was used), the usefulness of know that the 
server followed its policy is of questionable value. (I.e., this 
relates to the "middleboxes" - opaque entities in the network that do 
not yield sufficient information when it is needed for 
troubleshooting.)

2a) The "danger" is that a server is using an incorrect trusted key 
and is passing off data as AD'd.  Although this is correctable 
easily, without the ability to ask for the trusted key used, a 
"victim" can't easily determine that the problem is the incorrect key.

3) The only case in which the bit comes into play is when data 
arrives that is signed.  A setting of 1 means that the signature is 
germane and has been sufficiently checked.  A 0 means that the name 
server deemed the signature immaterial and did not check it.  I don't 
see that distinguishing between the two cases is of use to a stub 
resolver.

4) The need to redefine the bit is rooted in the DNSSEC workshops. 
Prior to the addition of logging to the software we tested (BIND), 
there was no way to determine if the name server's verification code 
kicked in.  We looked for the AD bit to indicate whether the trusted 
key statements and the zone signing was being performed correctly. 
Now, with logs available, this can be watched at the server.  I.e., 
the AD bit really is best used as a debugging tool at the server - 
but that role has been overcome by events (the addition of logging).

5) This is a speculative objection...What if the data srrives with 
the AD bit set to 0?  Is the resolver going to try and get a 
different answer?  What will the user (presuming the bit's setting 
bubbles up to the GUI) do?  Basically, somewhere along the line, a 
different name server is needed to find a better answer, will this 
happen in stub resolver situations?

Yes, I realize that in #2 I say that troubleshooting is a problem, 
and in #4 troubleshooting was helped.  In #2 I an talking about 
end-to-end troubleshooting, in which the shooter has no access to the 
server in question.  In #4 I am talking about troubleshooting of 
one's own server.

In summary - I don't see how this bit improves upon a correctly 
running DNS(SEC)  protocol.  (If you're going to trust the server to 
tell you it followed the protocol, trust the server to follow the 
protocol!)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 13 Jun 2002 14:43:48 +0200 (CEST)

> back end is DNSSEC-aware or not, unless you happen to know of a record

I've been assuming that 'some of the required signatures are invalid'
would mean that the data wouldn't be returned to the client.
Section 6 in 2535 might mean this by "not retained" below
but this is far from obvious:
   Data stored at a security aware server needs to be internally
   categorized as Authenticated, Pending, or Insecure. There is also a
   fourth transient state of Bad which indicates that all SIG checks
   have explicitly failed on the data. Such Bad data is not retained at
   a security aware server. Authenticated means that the data has a

My concern is that it seems really broken if the client can't easily
tell the difference between Insecure and Bad.

So what should a recursive resolver do whith Bad data?

  Erik

---

From: Greg Hudson <[email-masked]>
Date: 13 Jun 2002 10:49:57 -0400

> would mean that the data wouldn't be returned to the client.

Er, yes, presumably, since that's what you see if someone tries to spoof
a signed record.  So I should have written:

  AD=0 means the back end has not validated signatures, *or* the
  required signatures were absent.

Whether a recursive resolver should ever be forgiving with Bad data is
perhaps a debatable question, but I don't think it has much to do with
whether the AD bit is a good idea.  The same problem exists even if we
don't give any meaning to AD.

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 13 Jun 2002 12:10:21 -0500

on 6/12/2002 1:37 AM Robert Elz wrote:

> Note that the back end resolver (the one that received Rd=1, has RA=1,
> and actually sets the AD bit) has no method to know what kind of
> resolver is talking to it - it doesn't know whether the back end trusts
> it or not (it may know that it is going to use TSIG to communicate with
> its client, but presence of TSIG does not guarantee trust, nor does its
> absence prohibit it), so it just sets the AD bit (or doesn't) on all
> queries it processes, regardless of whether the value will end up being
> used or not.

First a disclaimer that I haven't fully internalized all of the DNSSEC
stuff so this has the potential to be a really stupid question.

It seems to me that there are a couple of problems that can be solved by
providing a way for the stub resolver to indicate whether or not the
calling application and/or the stub resolver is going to perform
validation, at which point there is only a question of how this desire
should be signalled.

I would think that using a flag in a psuedo OPT RR would handle this
nicely. On the one hand this tells the back-end resolver what kind of data
it needs to return (if the calling application or stub resolver is opaque
about DNSSEC then it only has to return the normal stuff). Secondarily,
the use of the OPT RR tells the back-end resolver that the stub resolver
is capable of accepting large messages containing all of the crap that the
stub and/or application needs. Would this work?

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Robert Elz <[email-masked]>
Date: Fri, 14 Jun 2002 13:39:05 +0700

Date:        Thu, 13 Jun 2002 14:43:48 +0200 (CEST)
    From:        Erik Nordmark <[email-masked]>
    Message-ID:  <[email-masked]>

  | I've been assuming that 'some of the required signatures are invalid'
  | would mean that the data wouldn't be returned to the client.

Maybe it does, but I would certainly hope that's not the expected
interpretation (by default).

That is, back end resolvers should (CD bit interpretation excepted)
always return answers to clients.

If the resolver has some way of determining that the data is "bad"
(including signature verification failing) then it can certainly
not "retain" the data (and most probably should not) - that is, it
should not cache it to give to some other unsuspecting client later,
as doing so would mean that it would have no chance of fetching
correct data until the TTL has expired (and that might be a very
long time sometimes - servers aren't required to place upper bounds on
TTLs they will accept).

But not returning data to the client means the client has no way of
figuring out what is going on - it can't tell the difference between
"I got an answer for you, but I didn't like the smell of it" from
"I never saw your query in the first place, sorry".   The right thing
to do is to send the answer to the client, certainly not indicating that
the answer is trustworthy in any way at all, and allow the client to
decide what to do.

Then we get to Ed Lewis' comments ...

  1) Name servers are already instructed to return only valid answers 
  (unless the CD bit was set on query)

OK, let's assume that we drop AD because if we care about what its
value would be, we will just leave CD clear, and  if AD would have been
0 in the reply, then the reply will never be sent anyway (or won't
contain any answers anyway).

Then let's assume that the back end resolver has never heard of DNSSEC
or SIG validation, or CD bits (or AD bits).   It will go out, discover
the answer, not even attempt to validate it, and return the answer to
the stub resolver.

Now, if you're one of Rob Austein's "smarter" resolvers, this is fine,
you just go do the SIG validation yourself, and all is OK (or not).

But if you're not, and there's no AD bit, how do you distinguish this
case from the one where the back end resolver is up to date, and did
the SIG validation for you, and all was OK?

Note that it is possible that the link between stub and back end is
using TSIG, and absolutely trusts the back end, in both of those cases.

The rest of Ed's concerns seem to boil down to

2) what does it mean for the back end to be trusted?

His points 2 and 2a were both relevant to that.   Certainly that's an
important question, but it isn't one that can be solved at this level.
The only solution to doubts at this level amounts to requiring all
stub resolvers, and everyone else, to do their own security checking.
And while from a very strict security viewpoint, that's probably the
best solution, it is also totally unrealistic.

3) seems to forget the case where the nameserver never heard of
signatures, and so returned AD=0 simply because it was one of the MBZ
bits...

4) I don't follow at all.   Maybe I'm missing something, as I was never
at one of the DNSSEC workshops, but how on earth is logging at the server
(back end resolver I assume you mean) going to possibly provide any
information at all to the stub resolver?   Nor can I imagine how anyone
could ever have believed that a bit in the packet would be useful as
a debugging tool for anyone, surely that was never why it was created?

5) What does the stub resolver do?   Whatever it likes - if for some reason
it wants a verified answer, and doesn't get one, then simply ignoring the
answer would seem to be right, just treat it as if no answer had ever
been received.  Typically that is going to cause it to go on to the next
back end resolver in its config list (even the dumbest stub resolvers need
to be able to handle more than one back end - just in case the one they
usually use is down when it is needed).   The response with AD==0 might
trigger a quicker retry than waiting upon a timeout.

Back to Erik again ...

  | My concern is that it seems really broken if the client can't easily
  | tell the difference between Insecure and Bad.

That's what it seems that AD (with CD) allows to happen.   If the
client sent to a security aware back end, then it won't get an
answer back, so it isn't going to get known bad data.   If the back
end didn't know about DNSSEC, then the answer will have AD==0, and
so the client will know it is insecure - may be bad, or might not
be (most probably will be OK, just as are all DNS answers now).

  | So what should a recursive resolver do whith Bad data?

Send it back (unless the client has expressly said not to) and then
throw it away.

kre

---

From: Edward Lewis <[email-masked]>
Date: Fri, 14 Jun 2002 09:34:20 -0400

>Then we get to Ed Lewis' comments ...

Hmmm[0], okay, so you are saying the AD bit could be useful in the 
case in which the stub resolver doesn't know if the back end is "old 
code", "new code without keys", or "new code with keys".  In this 
case, perhaps the bit should be a sign that the back end is doing 
'DNSSEC' or not.  (But this still leaves open the possibility that a 
"new code with keys" server has incorrect keys in it.)

In any case, I feel that it should be up to the configuration process 
to only admit servers (eg to /etc/resolv.conf) that are 
known/detected to be properly configured to return satisfactory 
answers.  A sneaking suspicion of mine is that building a "stub 
resolver hunting for a better answer" feature really gets us away 
from the spirit of the DNS protocol.  (Sneaking suspicions are always 
open to debate.)

>a debugging tool for anyone, surely that was never why it was created?

I should clarify.  The AD bit, showing up in dig was examined not for 
the benefit of the stub resolver, but to see if the back end did its 
job.  This is why the logging is a suitable replacement.  The AD bit 
wasn't intended for debugging, but that has become the bit's only use 
- and was the impetus for the new definition.

[0] - As in, ah, I see your point.  I hadn't really thought that case through.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Randy Bush <[email-masked]>
Date: Fri, 14 Jun 2002 08:23:27 -0700

> "new code with keys" server has incorrect keys in it.)

and what will they do with that knowledge?

> answers.

this is really the only decision point a stub has today.  and it does
not have the information necessary to make the decision.

randy

---

From: Robert Elz <[email-masked]>
Date: Fri, 14 Jun 2002 22:36:26 +0700

Date:        Fri, 14 Jun 2002 09:34:20 -0400
    From:        Edward Lewis <[email-masked]>
    Message-ID:  <a05111b02b92f99fff290@[192.149.252.173]>

  | In any case, I feel that it should be up to the configuration process 
  | to only admit servers (eg to /etc/resolv.conf) that are 
  | known/detected to be properly configured to return satisfactory 
  | answers.

Like I turn up to an IETF meeting and my laptop somehow (how?)
determines that the DNS back ends that the DHCP server tells me to
use are inappropriate, and throws them away?

How?   And what does it replace them with?

And worse, how does all this work with the still yet to be determined
IPv6 stateless DNS back end discovery algorithm?   Especially if
the "just use an anycast address" advocates manage to get their way.
How can one possibly tell if the server that will happen to respond to
a particular anycast address right now is one of the "properly configured"
ones or not?

  | I should clarify.  The AD bit, showing up in dig was examined not for 
  | the benefit of the stub resolver, but to see if the back end did its 
  | job.

Ah, OK, yes, I certainly agree that if that turned out to be the only
possible use of the thing, then deleting it would be the right thing
to do (and that would be true, even if logging hadn't improved...)

kre

---

From: Greg Hudson <[email-masked]>
Date: 14 Jun 2002 11:50:50 -0400

> interpretation (by default).

It has to be, or the major benefit of DNSSEC is lost.  If caches will
return signed-but-invalid data to stub resolvers, then attackers will be
able to spoof signed records, and only the people who do SIG checking in
their stub resolvers will be immune.

> The right thing to do is to send the answer to the client, certainly
> not indicating that the answer is trustworthy in any way at all, and
> allow the client to decide what to do.

In practice, stub resolvers do not "decide what to do" with answers from
the recursive resolver; they just take them.  Even if stub resolvers
were to get smarter, they don't have any information to make this
decision; without or without AD-is-secure, they can't distinguish
between an invalid signed record and an unsigned record.  And nobody is
going to configure their stub resolver to reject all unsigned records
any time soon.

Of course, as long as stub resolvers remain too stupid to at least use
TSIG, people can attack the path between the stub resolver and the
caching resolver.  But that path might be behind a firewall or within a
single machine, rendering it more difficult or impossible to attack.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 14 Jun 2002 11:56:56 -0400

>How?   And what does it replace them with?

How - that *is* the question!  That's exactly why I am against the AD 
bit - it only lets you know that the back end followed local policy, 
but there's no way to learn the local policy.

For now, I would replace the DHCP-suggested back ends with the 
servers "back home" in my /etc/resolve.conf.  Especially when I an 
testing TSIG protected activities.

>a particular anycast address right now is one of the "properly configured"

Bingo again!  Before I'd agree with any statement about a back end's 
policy, I want to be able to retrieve the policy (eg trusted key set).

---

From: Ted Lemon <[email-masked]>
Date: Fri, 14 Jun 2002 11:55:18 -0500

I must confess to being a bit surprised that anybody would even consider 
accepting an AD-is-secure bit from a name server with which their only 
relationship is that they saw its IP address in a DHCP packet.   Of course 
not.   You're going to run a local caching name server on your host that 
you know is configured the right way because you (or Microsoft, or Apple) 
configured it.

If your objection is that there's no way in the protocol to ensure that 
this has been done, I think it's not a good real-world objection.  In the 
real world, there are two classes of DNS users - those who consider it a 
black box, and those who care enough to mess with it.   Neither of these is 
a customer for a way of representing the secure resolver's security policy 
in the wire protocol.   The first group doesn't care - they want their 
vendor or sysadmin to set it up right, and if it's not set up right, they'
ll find out when they're defrauded.   The second group is going to 
administratively verify every part of their resolver system.   Where is the 
third group that you're talking about that needs a  verification system 
that operates in the wire protocol?

---

From: Randy Bush <[email-masked]>
Date: Fri, 14 Jun 2002 10:10:01 -0700

> I must confess to being a bit surprised that anybody would even
> consider accepting an AD-is-secure bit from a name server with
> which their only relationship is that they saw its IP address in
> a DHCP packet.

"accepting an AD-is-secure bit" is a bit difficult, as there is no
way or suggestion of what to do with the bit.  it is defined, but
there is no current way to pass it up through an API to an app, and
no guidance on what an app might do with that information if we
ever got it there.  i have visions of yet another ignored indicator
icon in the status line of one's fave browser.

and, for the vast majority of hosts, getting the address of the dns
server(s) to use via dhcp is the way of life.  and your implication
is right, dhcp is not known for its security.

> Of course not.  You're going to run a local caching name server
> on your host that you know is configured the right way because
> you (or Microsoft, or Apple) configured it.

does my win98 machine have a local caching nameserver?  [i mean the
question seriously] i know macs now have freebsd under them (yes!),
so it really could be a validating cacher underneath in that case.

randy

---

From: Paul Vixie <[email-masked]>
Date: Fri, 14 Jun 2002 10:14:23 -0700

> It has to be, or the major benefit of DNSSEC is lost.  [...]

So, six++ years into the experiment, we still don't agree on what problem
DNSSEC is supposed to solve, and what the underlying security model will be?

---

From: Robert Elz <[email-masked]>
Date: Sat, 15 Jun 2002 00:30:04 +0700

Date:        Fri, 14 Jun 2002 11:55:18 -0500
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | You're going to run a local caching name server on your host that 
  | you know is configured the right way because you (or Microsoft, or Apple) 
  | configured it.

You're thinking about the wrong kind of host.  Sure I could (but as it
happens, mostly don't) do that with PC/mac class systems, but am I
really going to be running a caching resolver in my mobile (cell) phone?
Or in my wristwatch for when it looks up the address of its NTP server?
Or in my light bulb for when it verifies the identity of the switch?

These are the kinds of things that really want to use stub resolvers.
They might also want to know that the answers have been verified (at
least that someone with whom they have some kind of relationship is
claiming that they're verified).

Code to do all of this lives in roms, and moderately large amounts of
that are feasible, easily.   A nameserver cache lives in ram, and that
means power to keep it running all the time.  That's not so easy.  It is
also only effective if the host is doing more than one lookup a week...

kre

---

From: Edward Lewis <[email-masked]>
Date: Fri, 14 Jun 2002 13:20:51 -0400

Assuming "you" is me (I'm in the To: field).

I agree with Ted's assessment.  One group won't care, the other will 
check themselves.  This is in roughly in line with my objection to 
defining the AD bit (or bothering to redefine it).

When I mention that the DNS protocol lacks the ability to transfer 
the "policy" of the server (keys), I am stating this as a reason why 
the AD bit is of dubious value.  I am not advocating extending the 
DNS protocol to transfer policy.

I should also say that in my arguements I have been trying to tie the 
reasons I object to the draft to technical issues (I understand). 
For this reason I have stayed away from stating "what 
users/applications will want" because I no expert there.  I see that 
the DNS protocol lacked what I mentioned before and rationalized that 
"if I can't see your rules, I don't care whether you followed them."

At 11:55 AM -0500 6/14/02, Ted Lemon wrote:
>If your objection is that there's no way in the protocol to ensure that this
>has been done, I think it's not a good real-world objection.

I'm assuming that by the above you mean that the lacking a means to 
get the policy isn't a sufficient reason to kill the AD bit.  You're 
right, it isn't.  But it is one of the reasons why I dislike the AD 
bit.

---

From: Robert Elz <[email-masked]>
Date: Sat, 15 Jun 2002 00:46:13 +0700

Date:        Fri, 14 Jun 2002 13:20:51 -0400
    From:        Edward Lewis <[email-masked]>
    Message-ID:  <a05111b03b92fd44c9c9c@[192.149.252.173]>

  | One group won't care, the other will check themselves.

This translates into "if you aren't able to check, then you're
not allowed to care".

Certainly from a pure security viewpoint, where all that matters is
perfect validation, that's not unreasonable.

But almost no-one needs that - remember that all security is a trade
off between the costs, and the benefits (as is almost everything else).

It is perfectly acceptable for people (hosts, ...) to agree to
permit some increased risk, in return for some lower cost.  That's
a tradeoff that everyone has to be permitted to make - and it is
not acceptable to simply write off anyone unable to get absolute
proof of correctness (nor to relegate them to "anything goes").

Eg: for many systems, simply trusting what the local resolver says
(without requiring it to be on the same net, and probably without
any special security measures) will be just fine.   If that resolver
has given me false information, then I know who to go and blame.
That, or the answer has been spoofed, and if my net is even half way
reasonably protected, I can usually limit the source of that spoofing
to somewhere local (filtering inbound source addresses, etc).
So, if there's spoofing, it is coming from somewhere local, and
whoever is responsible, either for spoofing, or leaving a system
open enough to allow it to be taken over, can be deal with.

Similarly, if the DHCP server gives me a bogus address as to where
I should query for my DNS answers.

For many users, that level of security is all that is required.
Don't demand that everyone have provably correct security, just
because you have been focused on that kind of issue (perhaps for
others who do need it) for so long, that everything else seems
hopeless.

By all means make sure the mechanisms are in place to allow good
security for those who need it - but don't then simply ignore everything
which isn't necessary in that perfect world.

kre

---

From: "Matt Larson" <[email-masked]>
Date: Fri, 14 Jun 2002 13:43:44 -0400

> icon in the status line of one's fave browser.

What good is DNSSEC going to do for anyone if an answer's security
status isn't conveyed to the user (in a manner appropriate to the
particular application)?  Why bother securing a zone at all if no
applications do anything with it?

> question seriously]

Nope.  Only W2K Server or better.

Matt

---

From: Randy Bush <[email-masked]>
Date: Fri, 14 Jun 2002 10:55:00 -0700

> DNSSEC is supposed to solve, and what the underlying security model will

you may find draft-ietf-dnsext-dns-threats-01.txt useful in this regard

randy

---

From: Greg Hudson <[email-masked]>
Date: 14 Jun 2002 13:52:28 -0400

> "if I can't see your rules, I don't care whether you followed them."

I take issue with your terminology.  First, AD does not mean "I followed
my rules."  It means "this record is signed and valid."  We have already
seen some confusion on this point.  Second, the phrase "local policy"
only applies to the AD bit when data is being served from a zone file. 
For data retrieved from other DNS servers, the only relevant "local
policy" is the preconfigured keys used by the caching resolver, and it
is very confusing to refer to the preconfigured keys using the general
term "local policy" when the AD-is-secure draft uses that phrase to mean
something else.

AD-is-secure applies to the case where you know enough about your
recursive resolver to trust it, and want to know whether records you've
asked for were signed or not.  It has nothing to do with discovering
information about a resolver you've just heard of.

---

From: Greg Hudson <[email-masked]>
Date: 14 Jun 2002 14:05:32 -0400

On Fri, 2002-06-14 at 13:43, Matt Larson wrote:
> > there is no current way to pass it up through an API to an app

I don't think this is true; Jakob Schlyter mentioned the
getrrsetbyname() API a few days ago.

> applications do anything with it?

The major benefit of DNSSEC is: signed records cannot be spoofed to
resolvers who do verification.

In order to realize that benefit, the resolver which performs
verification has to throw out records which fail verification, but pass
through records which can be verified to be unsigned.

But applications don't have to do anything special.

Paul Vixie wrote:
> So, six++ years into the experiment, we still don't agree on what
> problem DNSSEC is supposed to solve, and what the underlying security
> model will be?

Evidently not.  (Which doesn't mean the model isn't well-documented.)

---

From: Paul Vixie <[email-masked]>
Date: Fri, 14 Jun 2002 11:09:15 -0700

> you may find draft-ietf-dnsext-dns-threats-01.txt useful in this regard

i don't.  because there's no way to point the debaters on the AD thread
to it and say "if you don't like the security model, propose changes to
the language of that draft, otherwise shut up and let the ad-is-secure
thing go through, because it's a finishing touch to the model we've all
previously adopted."

---

From: Randy Bush <[email-masked]>
Date: Fri, 14 Jun 2002 11:11:32 -0700

> particular application)?

while i agree, i fear a very long security discussion of flavors of secure
and what an app would think about them.  [ i prefer mocha ]

> Why bother securing a zone at all if no applications do anything with it?

warm fuzzies when most of the dns data have been signed?

i can sign my part of the tree, but i can not force you to validate the
signatures.  so this may be a long-term game.  i suspect this is why some
folk focus on how things will act/scale when most of the data are signed
some years out.

randy

---

From: Rob Austein <[email-masked]>
Date: Fri, 14 Jun 2002 14:23:26 -0400

> Or in my light bulb for when it verifies the identity of the switch?

Yes, if doing so is the least painful way to accomplish the task for
which the device in question was created using security services
appropriate for the task at hand (I'm dubious about DNS-using light
switches, but let that pass).

> claiming that they're verified).

If they're part of an environment with stable and well-understood
trust relationships, I agree.  A light switch might fit this model.  I
doubt that a wrist watch or cell phone fits.

> also only effective if the host is doing more than one lookup a week...

Please see the previous discussion of caching recursive almost-stubs.
Long term caching is a service that the environment can provide.  The
device itself may only need to cache a small number of records, may
only need to do so for a fairly short period of time, or may be able
to tolerate a brief interval of less than complete functionality when
first powering up.

With all due respect, I think that this whole caching issue is largely
orthogonal to the security model discussion, and the latter is, I
think, the discussion that the WG really needs to have.

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 14 Jun 2002 13:28:38 -0500

[sorry for the dupe if you get one]

> so it really could be a validating cacher underneath in that case.

winsock2 systems have per-process caches, meaning that a lookup will be
cached for the TTL, but it doesn't have support for iterative queries

The MacOS resolver in 8.5 actually has iterative support, but it still
requires a local server to get the process started (if it only gets
delegation information but no answer, then it will go ask the delegation
target itself). I don't know what's in OS X but my guess would be that it
is the typical braindead stub in all other UNIXes.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 14 Jun 2002 14:31:04 -0400

At 1:52 PM -0400 6/14/02, Greg Hudson wrote:
>my rules."  It means "this record is signed and valid."  ...

For intance, look at RFC 3008:
1 - Introduction

    This document defines additional restrictions on DNSSEC signatures
    (SIG) records relating to their authority to sign associated data.
    The intent is to establish a standard policy followed by a secure
    resolver; this policy can be augmented by local rules.  This builds
    upon [RFC2535], updating section 2.3.6 of that document.

Note "local rules."  Whenever any validation is done in DNS, it is 
subject to local rules.  (This is a point of the DNSSEC protocol that 
is often overlooked.)  Whether a record is signed is an objective 
statement.  Whether the signature is valid is subjective.

I am short handing trusted keys and local policy.  The reason is that 
the trusted key set is the only part of local policy that has become 
concrete enough to use in an example.  Expressing authorization rules 
(what key is trusted to sign what data) has not been attempted.

>information about a resolver you've just heard of.

If you trust the recursive resolver, then trust it to follow the 
protocol rules.  No where in the protocol is a compliant recursive 
resolve allowed to send onward bad data - pending data than may be 
proven bad in a moment, but not bad data.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 14 Jun 2002 13:31:24 -0500

> icon in the status line of one's fave browser.

AFAIK, there isn't a standard that defines the resolver API, so this is a 
bit of a red herring.   If an application cares about the AD-is-secure bit,
  it will find a way to use it.   And I think it's plausible that an 
application might care about it - for example, I wouldn't mind a bit if my 
web browser were smart enough to stop me from sending a credit card number 
to a site the browser had reached in an insecure manner.   It's too early 
in the life of secure DNS for this to happen now, but I think it's 
reasonable to say that secure DNS might be part of a security validation 
process like this in the future.

> is right, dhcp is not known for its security.

A host that implements AD-is-secure can't use the DNS server listed in the 
DHCP packet as its resolver - it's that simple.   Even if DHCP were secure,
  that would still be true, because secure DHCP just means that you know 
which DHCP server you're talking to - it says nothing about the security 
policy at the site you happen to be connected to, as Ed has pointed out.

> so it really could be a validating cacher underneath in that case.

You can install a local caching nameserver on your Win98 machine, but by 
default it doesn't.   We are talking about the future, here, though.   If 
DNSSEC becomes something for which there is a market, Microsoft is neither 
stupid nor lazy - they will implement a secure DNS caching nameserver or 
something like it on Windows YO, or in .OFU (the next version of .NET).

---

From: Ted Lemon <[email-masked]>
Date: Fri, 14 Jun 2002 13:44:01 -0500

> I agree with Ted's assessment.  One group won't care, the other will check 
> themselves.  This is in roughly in line with my objection to defining the 
> AD bit (or bothering to redefine it).

I think  you missed part of my point, though.   On some level, some system 
somewhere has to tell the application "I was able to validate this data," 
or "this data was not signed."   I would say that there is no need for this 
system to be able to say "this data failed validation," because in that 
case it should just discard the data.   Whether that validation is 
something that needs to be set in the protocol, with a bit, is something 
that I have to admit I am not qualified to say, but if applications use 
stub resolvers, it seems clear that it would be necessary.

> I see that the DNS protocol lacked what I mentioned before and 
> rationalized that "if I can't see your rules, I don't care whether you 
> followed them."

You have to be careful to identify who "I" is in this case.   In the case 
of the black box user, "I" is not the user - it is the author of the 
application that the black box user trusts.   And "your rules" are rules 
that are probably guaranteed by the operating system - this is why it's 
important whether there's a caching resolver on the system that's setting 
the ADis bit.

If you are an under-the-hood kind of guy, then "I" is the user - you.   And 
"your rules" are also the user's rules - your rules - because you set up 
the caching resolver that's doing the verification.

So in both cases, *if* the application cares about ADis, and *if* the 
application isn't going to do the name resolution process itself, the ADis 
bit is useful.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 14 Jun 2002 13:50:26 -0500

> Or in my light bulb for when it verifies the identity of the switch?

If you can believe that there's going to be a network connection to your 
light bulb, I don't see why thinking that the light bulb will have a 
caching resolver is any more of a stretch.   At this point the computer in 
my cell phone is a lot mobier than my first PC, and I'm quite sure I could 
have gotten a caching resolver running on my first PC if I'd cared to do so.

> also only effective if the host is doing more than one lookup a week...

Then maybe this is a case where you don't need the ADis bit, because the 
application would just do the lookup and verify the signatures itself.

---

From: "Andy W. Barclay" <[email-masked]>
Date: Fri, 14 Jun 2002 18:38:06 -0700

After reading draft-ietf-dnsext-dns-threats-01.txt, it has occurred to 
me that DNSSEC may be a waste of time.

It seems that applications are capable of the same security that we can 
provide with DNSSEC. (I realize that if we could get a global 
deployment, we could increase security on legacy protocols).

For example, the draft referenced above says:
"The resulting list of desired security services was
      1) data integrity, and
      2) data origin authentication."

Any application that uses certificates has those capabilities. Legacy 
applications that require security are being upgraded to support 
certificates/keys (ntp).

Can someone convince me that DNSSEC still makes sense?
(One argument that I won't buy into is that my phone/PIM or whatever 
doesn't have the horsepower to do certificates. By the time we get 
dnssec deployed, they will have that horsepower.)

-- 
Regards,
Andy W. Barclay.        [email-masked]
fax  (781) 823-8276
Always a UNIX Evangelist (and sometimes a system and network architect)

"Money, not morality, is the principle commerce of
civilized nations"
    -- Thomas Jefferson

---

From: [email-masked]
Date: Sat, 15 Jun 2002 12:10:35 +1000

> dnssec deployed, they will have that horsepower.)

	DNS is just another application trying to secure its own
	transactions using cryptography.  You have no problem with
	NTP using cryptography to secure its transactions.  What's
	your problem with DNS using cryptography to secure its
	transactions.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Greg Hudson <[email-masked]>
Date: 14 Jun 2002 22:18:38 -0400

The primary purpose of DNSSEC is to protect the DNS infrastructure,
which is mostly name-to-address and address-to-name mappings, not to
provide security for applications.  There are those of us who wouldn't
mind being able to use DNSSEC to protect application keys, perhaps
because of a dislike of X.509 certificates or the certificate model in
general, but that's a separate problem.

You could argue that protecting infrastructure is pointless; that
everyone should use secure application protocols instead.  I wouldn't
agree, though:  Defense in depth is a fine thing.

For instance, right now, if you want to attack www.amazon.com, you can
simply spoof its DNS record to some set of clients to point to your own
web server, which is a replica of www.amazon.com except it never uses
SSL.  The vast majority of users are unlikely to notice.  You'll be
detected eventually, but not before you steal some large number of
credit card numbers and/or sales.

With DNSSEC deployment to the www.amazon.com record and the resolvers of
most users, this attack gets harder.  You can't spoof the DNS record, so
you have to hijack TCP connections or do something similarly difficult.

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 15 Jun 2002 11:56:09 +0200

"Andy W. Barclay" <[email-masked]> writes:

> It seems that applications are capable of the same security that we
> can provide with DNSSEC. (I realize that if we could get a global

One of the design goals with DNSSEC was to distribute keys used not
only for securing the DNSSEC infrastructure, but also for use by
applications in general.  This is still not commonly implemented, but
is IMHO the main feature of DNSSEC.  The RFC 2535 abstract is
refreshlingly clear about this being on of the goals:

,----
|    The extensions provide for the storage of authenticated public keys
|    in the DNS.  This storage of keys can support general public key
|    distribution services as well as DNS security.  The stored keys
|    enable security aware resolvers to learn the authenticating key of
|    zones in addition to those for which they are initially configured.
|    Keys associated with DNS names can be retrieved to support other
|    protocols.  Provision is made for a variety of key types and
|    algorithms.
`----

---

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

---

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.

---

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

At 11:42 PM -0500 6/15/02, Ted Lemon wrote:
>somewhere?   I don't understand your point about bad keys, so maybe 
>I'm missing something.

You and Greg are hitting on the same point - that the information 
conveyed by the AD bit is important to the application.  My response 
now is that this is an API issue, not a protocol issue.

Perhaps there is a benefit there, but I certainly didn't get it from 
the draft.  I usually think in terms of server to server to stub 
interactions, but I rarely consider what happens at the application 
level.

Quoting the message that started this all, at 3:54 PM +0200 6/10/02, 
by Erik Nordmark I see that my failure to grasp that this was an 
application API issue may lay in comments already leveled against the

---

From: "Andy W. Barclay" <[email-masked]>
Date: Sun, 16 Jun 2002 08:03:43 -0700

But DNS is not just another application. I can't think of any case
where the application is just DNS. Its always another application
that uses the data in DNS (like mozilla, xntp, ssh, sendmail, etc.)
Many people are talking about modifying the application to deal with
the AD bit. I'm becoming even more convinced now, that if I'm modifying
the application, I might as well modify it to simply use certificates.

It takes a long time to understand nothing.
    --EDWARD DAHLBERG

---

From: "Andy W. Barclay" <[email-masked]>
Date: Sun, 16 Jun 2002 08:17:47 -0700

> general, but that's a separate problem.

I am one of those people.

> everyone should use secure application protocols instead.  

This is precisely my point. I'm arguing that protecting DNS maybe
pointless, and I'm looking to be convinced that it makes sense.

> I wouldn't

Ok, so your argument is that its worthwhile to protect legacy protocols.
My argument is that if we are modifying the applications anyway, why
not have the "default" protocol of the web browser be https? In this
way, if someone has spoofed the address, then the user will get
a dialog box indicating a certificate mismatch. I realize that there
is still a class of users that will simply dismiss this dialog box, and
continue to use the site, but that same class of users would probably
also dismiss the box that says "the DNS name could not be 
authenticated". Actually, its probably worse, because there is a larger
class of users that, during deployement, would get so annoyed at this
warning, that they would check the "don't tell me this again" box.

> you have to hijack TCP connections or do something similarly difficult.

yes, you are correct, assuming that the application or resolver has been 
modified to check signatures, or if the application trusts its local
nameserver.

---

From: "Eric A. Hall" <[email-masked]>
Date: Sun, 16 Jun 2002 10:52:53 -0500

> that uses the data in DNS (like mozilla, xntp, ssh, sendmail, etc.)

This should not be taken as an endorsement of Andy's argument, but it is
worth pointing out that if the application isn't part of the security
chain then attacks can be moved to some other naming service that the
application or resolver implicitly trusts. Hacking into /etc/hosts on a
few thousand boxes is impractical but using a virus to infect a few
thousand PCs isn't. Changing an NIS or LDAP naming service would also be
productive for redirecting traffic at least within a local administrative
domain. The only way that the e2e argument holds up is if the application
which is issuing the lookups does the validation; the application is the
participating end-point, not the resolver.

Of course, the local security policies of any given opsys are probably
well beyond the scope of this WG. It might be worth mentioning some of
these issues in a security considerations section of an update though,
especially the requirement for applications to participate.

Also of course, if there's some switch that needs to be defined in order
for an application to actively and effeciently participate then that is in
scope, and the switch should be defined somewhere.

---

From: "Andy W. Barclay" <[email-masked]>
Date: Sun, 16 Jun 2002 09:01:36 -0700

I agree about using DNS to distribute keys, and that would convince me 
that DNSSEC is still worthwhile, however, with the draft suggestion to 
limit the KEY RR, and with DNSSEC taking so long to be deployed, I feel 
that people requiring secure key-based protocols won't wait for
DNSsec. I've checked the working group drafts, and I can't find any
that are working on storing application keys in the DNS. Is anyone aware
of work being done in this area - possibly outside the WG?

---

From: Greg Hudson <[email-masked]>
Date: 16 Jun 2002 12:14:57 -0400

> of work being done in this area - possibly outside the WG?

I think there are some people experimenting with doing this for ssh and
possibly for IPsec.

Both of those applications already have their own specialized security
protocol which merely needs to be seeded with a private key.  Most
applications are not in that situation, and no one in an application
working group wants to invent a new security protocol just to get a
particular key management behavior.

Perhaps the easiest way to gain acceptance would be to define SASL
and/or GSSAPI mechanisms which use keys or key fingerprints in DNS,
protected by DNSSEC, to bootstrap a security association.  (People who
don't want to trust the DNS authority chain could use other mechanisms,
so Keith's objection would be covered, I think.)  Still a difficult
road, though.

---

From: Jakob Schlyter <[email-masked]>
Date: Sun, 16 Jun 2002 18:23:05 +0200 (CEST)

On Sun, 16 Jun 2002, Andy W. Barclay wrote:

> I've checked the working group drafts, and I can't find any that are
> working on storing application keys in the DNS. Is anyone aware of work
> being done in this area - possibly outside the WG?

draft-schlyter-appkey-02.txt
draft-schlyter-pkix-dns-02.txt

	jakob

---

From: Edward Lewis <[email-masked]>
Date: Sun, 16 Jun 2002 13:51:24 -0400

At the urging of some off-list messages, I was urged to re-read the 
draft and figure out why I'm running so contrary to the consensus.

I still find the draft lacking, as was noted in Eric's message, but 
after considering the post-IESG feedback mail thread, the AD bit 
makes more sense.

The problem is that I have been afraid of putting the bit into 
"general use."  Perhaps it is the specification style of the draft, 
but it is not until the last paragraph of the Security Considerations 
is the crucial text:

So, the authors assume that there is no need to transfer policy 
because the receiver already know the sender's policy.  And I take 
"knowing" to include "I know the administrator of that server and if 
I get burned, I can ask her to update the keys."

In addition, this passage, which I *have been* aware of, doesn't 
appear until the last paragraph of section 3.  This should be brought 
forward in the document.

    A resolver MUST NOT blindly trust the AD bit unless it communicates
    with the server over a secure transport mechanism or using message
    authentication such as TSIG [RFC2845] or SIG(0) [RFC2931] and is
    configured to trust the server.

So, if the AD bit constricted to be meaningful only between mutually 
consenting resolver and server, defining it to mean that the server 
followed the DNSSEC policy makes sense.

The up shot for me is that I would support this redefinition of the 
bit if the authors make the restrictions "buried" late in the 
document are promoted to the introduction.

Perhaps buried is a strong term, but I really dislike any 
specification or constraint language in the "* considerations" that 
hasn't appeared earlier.  I prefer to just put analysis in those 
sections, e.g., listing the consequences of voiding parts of the 
specifications.  In this instance, the security considerations should 
mention that blindly trusting the AD bit may result in trusting an 
unverifiable (even out of band) server, etc.

Finally - if the intent of the AD is to enable applications to report 
the use of validated data, then this ought to be mentioned in the 
introduction.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Edward Lewis <[email-masked]>
Date: Sun, 16 Jun 2002 17:07:31 -0400

I can't even let myself have the last word.  Given the following 
passage, I would urge the addition of this in section 2:

"The AD bit SHOULD NOT be set unless TSIG/SIG(0) is being used to 
protect the response."  "SHOULD" appears because local policy might 
dictate otherwise.  This is would reinforce the notion below.

At 1:51 PM -0400 6/16/02, Edward Lewis wrote:
>but it is not until the last paragraph of the Security 
>Considerations is the crucial text:
>

---

From: Donald Eastlake 3rd <[email-masked]>
Date: Sun, 16 Jun 2002 20:08:22 -0400 (EDT)

On Sun, 16 Jun 2002, Edward Lewis wrote:

> Date: Sun, 16 Jun 2002 13:51:24 -0400
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: IESG feedback on dnsext-ad-is-secure
>
> ...
>
> ...

It is common for their to be resolvers, such as those on machines within
a company, that are more or less required to follow the
resolution/security policies of corporate level or border recursive
servers, whether they know, like, or approve of such resolution/security
policies.

Donald

---

From: [email-masked]
Date: Mon, 17 Jun 2002 10:34:41 +1000

> the application, I might as well modify it to simply use certificates.

	While certificates will *detect* that you have the *wrong*
	address they won't help you *get* the *right* address.
	DNSSEC will do that by allowing the nameserver to reject
	the bogus data and wait for the good data to arrive.  DNSSEC
	reduces the attack at the DNS level to a DoS attack not a
	insertion attack.

	The DoS attacks come in (at least) two forms.
	1. computation attack
	2. blocking the valid answers being received which requires
	   that the attacker is controlling equipment on the path
	   between the nameservers involved.
 
	Mark

---

From: Edward Lewis <[email-masked]>
Date: Sun, 16 Jun 2002 20:42:38 -0400

I had this in mind when I wrote what I did.  I.e., when working on 
company business, if that business is hosed by faulty DNS security, I 
"know" how to complain to the IT department (or whoever is running 
the DNS).

And when I later posted that perhaps "SHOULD NOT set the bit w/o 
TSIG/SIG(0)", the SHOULD NOT was just that for a case like this (as 
opposed to "MUST NOT").

Security is relative - you can only be as secure as your environs 
allow.  When I have worked in the clutches of less-than-optimum 
bureaucracies, I just learned to go with the flow.  When corporations 
lay down such a requirement on employees, there isn't much to fight. 
(This applies to the work assets, not the personal assets, of the 
employees.)

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Mon, 17 Jun 2002 00:24:18 -0400

At 01:51 PM 6/16/2002, Edward Lewis wrote:
>At the urging of some off-list messages, I was urged to re-read the draft 
>and figure out why I'm running so contrary to the consensus.
>
>I still find the draft lacking, as was noted in Eric's message, but after 
>considering the post-IESG feedback mail thread, the AD bit makes more sense.

Finally a constructive comments on the draft from Ed, I guess the
unreported yelling and cursing at him at the Black Helicopter meeting
helped :-)

>The problem is that I have been afraid of putting the bit into "general 
>use."  Perhaps it is the specification style of the draft, but it is not 
>until the last paragraph of the Security Considerations is the crucial text:
>
>So, the authors assume that there is no need to transfer policy because 
>the receiver already know the sender's policy.  And I take "knowing" to 
>include "I know the administrator of that server and if I get burned, I 
>can ask her to update the keys."
>
>In addition, this passage, which I *have been* aware of, doesn't appear 
>until the last paragraph of section 3.  This should be brought forward in 
>the document.
>
>The up shot for me is that I would support this redefinition of the bit if 
>the authors make the restrictions "buried" late in the document are 
>promoted to the introduction.

Will gladly do this,

>Perhaps buried is a strong term, but I really dislike any specification or 
>constraint language in the "* considerations" that hasn't appeared 
>earlier.  I prefer to just put analysis in those sections, e.g., listing 
>the consequences of voiding parts of the specifications.  In this 
>instance, the security considerations should mention that blindly trusting 
>the AD bit may result in trusting an unverifiable (even out of band) 
>server, etc.
>
>Finally - if the intent of the AD is to enable applications to report the 
>use of validated data, then this ought to be mentioned in the introduction.

s/application to report/stub resolvers to report to applications/

The original motivation for this draft was to enable REMOTE TRUSTED
recursive resolvers to signal validation status to local stub resolver,
thus enabling it to pass this information on to the application.
The use of this bit by protocol elements (read resolvers) was limited
to policy directives by applications such as:
         accept only validated KEY records
         accept any CERT records

These issues are API issues and well outside DNS protocol, but it
is important that DNS protocol carry this information to leaf notes
that depend on "servers" to do the heavy lifting of DNSSEC.

         Olafur

         Olafur

---

From: Roy Arends <[email-masked]>
Date: Mon, 17 Jun 2002 14:31:50 +0200 (CEST)

>    the answer and authority sections of the response are Authenticated."

A negative response, containing opt-in NXT records do not fail that test.
Setting AD on a response for a query (regardless where from) indicates
that all RRsets present in answer and authority section have been
validated. This does not mean that QNAME and or QTYPE do not exist.

This implies that the entity receiving the response can interpret the
difference between 2535-NXT and opt-in-NXT. This intelligence is nowhere
implied, and thus there is ambiguity. 

Roy

---

From: Roy Arends <[email-masked]>
Date: Mon, 17 Jun 2002 14:51:12 +0200 (CEST)

Roy

---

From: Edward Lewis <[email-masked]>
Date: Mon, 17 Jun 2002 08:47:48 -0400

At 9:14 AM +0200 6/17/02, Simon Josefsson wrote:
>
>Should it really restrict it to TSIG/SIG(0) only?  What if I run IPSEC
>to my local DNS cache, and the DNS cache understands this?

Yeah - I wasn't about to exhaust the run of possibilities.  And 
that's why I used "SHOULD NOT."

'Course the question is how to implement the choice.  It could be a 
run-time option, with the default to clear the bit unless the in-bad 
protections are used.  I don't think it would be proper to delve into 
whether one implementation or another can or can not detect the IPsec 
security associations in use.

...But the spirit of the comment should account for your suggestion.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 17 Jun 2002 09:14:56 +0200

---

From: Brian Wellington <[email-masked]>
Date: Mon, 17 Jun 2002 15:36:15 -0700 (PDT)

> to my local DNS cache, and the DNS cache understands this?

Or if the client and cache are on the same machine.  I think I trust the 
loopback interface without crypto.

Brian

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 21 Jun 2002 10:58:12 +0200 (CEST)

> case it should just discard the data.  

"this data failed validation" could mean two different things:
1. the SIGs didn't verify correctly
2. unable to verify the SIGs because the necessary keys were not available
   2A. because the resolver timed out trying to retrieve one or more of them
   2B. because some SIGs/KEYs are not present higher up in the tree and
       the resolver is not configured with keys for zones below this "gap"

Add to that the cases of
3. No SIG for the RRset (DNSsec not used). Presumably upper parts of the
   tree could use DNSsec. Would the client care that . and .com was verified
   with DNSSEC when example.com did not use DNSSEC?
4. DNSSEC and everything verifies correctly.

The question I have is what of these cases need to be communicated to the stub
and how that is done. AD can easily distiguish between 3 and 4.
If #1 means that the recursive resolver should not pass the RRset at all
to the stub (but there seems to be different opinions here)
then what remains is case 2.

  Erik

---

From: Ted Lemon <[email-masked]>
Date: Fri, 21 Jun 2002 10:44:12 -0500

>        the resolver is not configured with keys for zones below this "gap"

If the resolver was able to get the data, but not the keys that sign the 
data, I would say that this is indicative of something worrisome, and one 
could argue that the data should be discarded, just as when the SIGs don't 
verify.

If the resolver can't verify the data because *it* is not configured to do 
so, then it can't really make any assertions about the correctness of the 
data, so AD should be zero and the data should be passed to the application.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 25 Jun 2002 02:48:43 -0400 (EDT)

> the document is a good idea.

This is not the intent of the document and this behavior is
outlawed in the security consideration, by classifying such resolvers
as "not security aware".
Next version will contain more explicit text.

> examples of what the application will do based on the value of the bit?

The main motivation is to allow in-protocol transfer of security status of
answer, from a full function DNSSEC resolver to a trusting (possibly less
capable) one.
I know of at least one API that transfers this information.
But that is not the point, by not providing the AD bit (functionality)
we require full function DNSSEC resolver on every host. This breaks the
current DNS resolver deployment model more than the designers of DNSSEC
where willing/allowed to go.

Example: SSH client can report:
  do you want to connect to:
	 client <foo> with  <addr> (DNSSEC protected)
	 and has key footprint <blah> (DNSSEC protected)

If this is the first time you are connecting,  this message is
gives you more confidence that you are actually connecting to the right
host. Or the SSH client may have a configuration parameters that do
not allow connecting to a host unless the key for the host is in the
known-keys file or some information about the key is DNSSEC
protected (say foot print or APPKEY).

Another option is that resolver get directions from application such as:
"Only reture Secure data"

There are two ways to get this information between two resolvers
via the AD bit, or via some new (unspecified) EDNS option.
I (speaking as half of the authors of this document) belive that
AD is sufficient, as in most cases application will only care if the
answer "secure or not".

As pointed out in a later e-mail by Ed Lewis some applications may care
about how the answer was reached, for example is the security status
verified by a chain leading to the ROOT or to a configured trusted key
lower in the tree.
AD bit does not help here, ENDS option may.
Similary ENDS option may allow the return of both validated and
not validated data in the answer and authority sections.

> setting where the ISP would run the resolver.

Agreed, will add some text to this effect.

> as it stands, what problem are we trying to solve by making the

The draft version I have right now contains the background on why
this work was started:  (something like this will be in the next version).
	- Stub resolvers may not be able to do this work
	- The local cache is going to do the work anyway so why repeat it?
	- In the islands of security model maintaining current list of
	  trusted roots for each island in every resolver inside an
	  organization it is simpler to maintain few servers and have
	  all the resolvers trust them.

> Smaller issues

Fixed.

> new behavior. Is section 2.2 unmodified or new behavior?

Both, this is a clarification of what RFC2535 is trying to say.

> to instead say "the definition of the Authentic Data (AD) bit in RFC 2535 ...".

Fixed.

> that undefined term adds any clarity.

Security aware is a term from RFC2535 (and RFC2065).
Reworded this paragraph to make it more explicit what the intent is.

> IP address of the recursive resolver. (e.g. using DHCP).

Agreed, AD is only for consenting adults to use :-).

> the rfc-editor's instructions.

Done.

> >   application running on a host that has trust relationship with the

Fixed.

> sigs verified, or server is authoritative.

s/checked/cryptographically verified/

>    using the updated definition, which is any server supporting the OK

it was in there but, I added the "OK bit" to be explicit.

	Olafur

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 25 Jun 2002 10:22:50 +0200 (CEST)

> Both, this is a clarification of what RFC2535 is trying to say.

It would be more clear if it says e.g.
	Replace section X.Y in 2535 with
		blah blah blah
or
	The paragraph in section X.Y in 2535 which says
		foobar ...
	is replaced by this document with
		blah blah blah

  Erik