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

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

On Thu, 2002-06-13 at 08:43, Erik Nordmark wrote:
> 
> > 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.

> I've been assuming that 'some of the required signatures are invalid'
> 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.

--
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: 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).