Subject: Q31: Validator behavior for islands of security

From: "Scott Rose" <[email-masked]>
Date: Tue, 6 Apr 2004 12:10:18 -0400

Question:  What is default behavior when a validator cannot get a secure
entry point into an island of security?

In proto-05 section 5.1, there is the discussion on the resolution process
and islands of security (or self-signed zones with no secure delegation).
The last sentence in the first paragraph reads:

     If a validator cannot obtain such a key, it will have
     to choose whether to accept the unvalidated responses
     or not based on local policy.

The suggested change:

	If a validator cannot obtain such a key, it
      SHOULD switch to operating as if the zones
	in the island of security are unsigned.

Background:
RFC 2535 mentions islands of security, but gives no specific handling
instructions.  RFC
3090 (DNS Security Extensions on Zone Status) section 1.2 states that "The
only way in which a DNSSEC resolver will come to trust any data from this
island is if the resolver is pre-configured with the zone key(s)... Other
resolvers (not so configured) will recognize this island as unsecured."
This change attempts to bring the spec in line (and strengthen) with RFC
3090.

This question is not an attempt to raise the same topics as DNSSECbis Q28 on
how a validator and resolver should act with regards to unsigned or invalid
signatures.

This has not be explicitly discussed on namedroppers (to my knowledge).
Section 5.1 does not go into detail how a validator treats unsigned zones,
but that was to be discussed in another section on classifying responses.
Simply put, Section 5.1 should only state that the data should be treated as
unsigned.  How unsigned data is handled by the validator and the info given
back to the resolver are discussed in other sections.

Deadline:
If there is no specific reason not to change this paragraph in Section 5.1,
the change will be made by April 19.

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