Subject: Q-28 Clarification of the scope of the document set.

From: Olaf Kolkman <[email-masked]>
Date: Tue, 3 Feb 2004 14:07:21 +0100

Q-28 Clarification of the scope of the document set.

This is not a protocol issue, but also more than an editorial nit,
hence a question to the WG.

It is about language to be added to several parts of the document set;
During recent discussions it has became clear that some of the
architectural considerations where too implicit.

This is a first go at a draft of text that is to be added to the intro 
document. It
needs some work on the details. It has been sitting on my disk for a 
bit but I
have not been able to concentrate on it for the last few days
(the reason is on www.geerthe,org :-) ).

Note that I think that definitions of new RCODEs or EDNS0 extensions or 
other
solutions to 'solve' the last mile communications is out of scope.

--Olaf

<proposed intro text>

In the DNSSEC architecture the security aware resolver determines if
DNS deta is in one of three states "unsecure", "validated" or
"bogus". The specification in these document set is designed to make
sure these 3 states can unambiguously be determined from the answers
that are returned from security aware servers.

Validated: Data is "validated" if one of possibly multiple
         authentication chains from a trust anchor to the data itself
         can be established. Multiple authentication chains can exist
         when there are multiple DS RRs at a delegation point or when
         data is covered by multiple RRSIGs.  A security aware resolver
         may not have all possible authorization chains at its
         disposal, either because an authorization chain is based on an
         algorithm that has not been implemented or because there is no
         trust anchor for a possible authenticatio chain available.

Unsecure: If no authentication chain can be established; either
         because there is no appropriate trust anchor or the
         authentication chain was broken because of the authenticated
         absence of DS RRs that point to keys of algorithms the
         resolver is able to use.

         If there are no trust anchors configured than all data is
         marked insecure.

Bogus: Data that is neither validated nor unsecure: Somewhere in the
        authentication chain there was an RRset for which all of the
        RRSIG RRs did not cryptographicly verify or were intended for a
        different time interval. Alternatively not all needed links in
        the authorization chain are available e.g. because network
        failures.

Once security aware resolvers have determined if data is 'secure',
'insecure' or 'bogus' their work is done. This specification does not
define a format for communicating why data was found to be bogus or
insecure. For the communication between a security aware recursive
servers and security aware stub resolvers this specification defines a
default policy for communicating the 3 states. The detailed
specification of a method for signaling advanced error codes and or
policy between a security aware stub resolver and security aware
recursive nameservers is subject to future work.

</proposed intro text>

In addition to this text there is language to be added to the protocol
document that defines the behavior for security aware recursive
nameservers. Roughly (because the CD bit behavior is ignored for now) 
like:

If the security aware recursive nameserver validates data as "unsecure"
it forwards data to the the security aware stub resolver without the
ad bit set.

If the security aware recursive nameserver validates data as "secure"
it forwards data to the the security aware stub resolver with the
ad bit set.

If the security aware recursive nameserver validates data as "bogus"
it returns an answer with RCODE=SERVFAIL

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