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

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:

On Mon, 2002-06-10 at 09:54, Erik Nordmark wrote:
> 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?

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

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

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

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.

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

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.

--
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: Olafur Gudmundsson <[email-masked]>
Date: Tue, 25 Jun 2002 02:48:43 -0400 (EDT)

On Mon, 10 Jun 2002, Erik Nordmark wrote:

> Folks,
>
> The IESG reviewed draft-ietf-dnsext-ad-is-secure-05.txt and has
> some significant concerns. While the document just tries to make

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.

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

Agreed, will add some text to this effect.

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

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

Fixed.

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

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

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

Fixed.

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

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

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

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

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

Done.

>
>
> Nits
> ----
>
> >   application running on a host that has trust relationship with the
>
> s/has/has a/

Fixed.

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

s/checked/cryptographically verified/

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

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

	Olafur