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

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

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?

> Option 2 might be better, but it would probably require a TCP fallback
> 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.

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

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

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

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

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

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

> There is one common case where that trust is perfectly justified: the
> 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: Erik Nordmark <[email-masked]>
Date: Tue, 11 Jun 2002 17:44:03 +0200 (CEST)

> stub resolvers already have blind trust in their recursive servers.
> (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: 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.)

At 8:08 PM -0400 6/16/02, Donald Eastlake 3rd wrote:
>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.

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

---

From: Danny Mayer <[email-masked]>
Date: Sun, 16 Jun 2002 22:18:44 -0400

At 01:43 PM 6/14/02, Matt Larson wrote:
> > does my win98 machine have a local caching nameserver?  [i mean the
> > question seriously]
>
>Nope.  Only W2K Server or better.

W2K Pro and Server have a DNS Client Service that caches responses.
If you're running DNS such as BIND, you really have to turn it off to prevent
it interfering with the DNS server for lookups on the local machine.

I have no idea whether or not any of the Win9x O/S's cache responses
but then I find Win9x scarier than the NT/2K O/S's since it has no security
at all.

Danny

---

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

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

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