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

[Olafur Gudmundsson <[e-mail]>]

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

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.

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

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

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






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