IESG feedback on dnsext-ad-is-secure

[Erik Nordmark <[e-mail]>]

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 [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>