Subject: Clarification questions for trust anchor handling

From: Andrew Sullivan/dnsext co-chair <[email-masked]>
Date: Wed, 11 Jun 2008 17:12:01 -0400

Dear colleagues,

Given that it is apparent different people have different impressions
of the requirements for handling locally-configured trust anchors as
compared to chains of trust followed from somewhere up the tree, we
need clarifying text.  We propose that this clarifying text should go
in draft-ietf-dnsext-dnssec-bis-updates.

In order to allow the editors of that document to propose text, we
would like the members of the working group to answer the following
questions.

A.  MAY validating resolvers use a local policy to enforce certain
validation methods, e.g. by using only locally-configured trust
anchors even when there is a valid chain of trust available? 

B. If the answer to (A) is, "Yes," what should the default policy be?

C.  Should the following text from RFC 4035 be read as extending to
trust anchors?  Please note section 4.2 of the (expired)
draft-ietf-dnsext-dnssec-bis-updates-06 and suggest alteration as
appropriate.

> 5.1.  Special Considerations for Islands of Security

>    Islands of security (see [RFC4033]) are signed zones for which it is
>    not possible to construct an authentication chain to the zone from
>    its parent.  Validating signatures within an island of security
>    requires that the validator have some other means of obtaining an
>    initial authenticated zone key for the island.  If a validator cannot
>    obtain such a key, it SHOULD switch to operating as if the zones in
>    the island of security are unsigned.

>    All the normal processes for validating responses apply to islands of
>    security.  The only difference between normal validation and
>    validation within an island of security is in how the validator
>    obtains a trust anchor for the authentication chain.
[. . .]
> 5.3.1.  Checking the RRSIG RR Validity
[. . .]
>    It is possible for more than one DNSKEY RR to match the conditions
>    above.  In this case, the validator cannot predetermine which DNSKEY
>    RR to use to authenticate the signature, and it MUST try each
>    matching DNSKEY RR until either the signature is validated or the
>    validator has run out of matching public keys to try.

>    Note that this authentication process is only meaningful if the
>    validator authenticates the DNSKEY RR before using it to validate
>    signatures.  The matching DNSKEY RR is considered to be authentic if:

>    o  the apex DNSKEY RRset containing the DNSKEY RR is considered
>       authentic; or

>    o  the RRset covered by the RRSIG RR is the apex DNSKEY RRset itself,
>       and the DNSKEY RR either matches an authenticated DS RR from the
>       parent zone or matches a trust anchor.

Olafur & Andrew

-- 
Andrew Sullivan
[email-masked]
+1 503 667 4564 x104
http://www.commandprompt.com/

--
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: [email-masked]
Date: Thu, 12 Jun 2008 00:05:25 +0100

> anchors even when there is a valid chain of trust available? 

Yes.

> B. If the answer to (A) is, "Yes," what should the default policy be?

Logical OR. At least one of the available chains of trust must validate. 
When ALL the available chains of trust do NOT result in a correctly 
validated signature, the validated RRSet is bogus.

> >       parent zone or matches a trust anchor.

Yes.

Roy Arends
Nominet UK

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 11 Jun 2008 20:12:55 -0300

> anchors even when there is a valid chain of trust available? 

Yes. But I think the sample the way it's stated it's ambiguous,
because both TA are locally-configured. You'll have two or more TA at
different levels of the tree. e.g. by using only the more specific
trust anchor even when there is a valid chain of trust available from
another trust anchor upper in the tree.

> B. If the answer to (A) is, "Yes," what should the default policy be?

Default policy should be that all chains of trust available must be
tested and the default test order should be from the less specifict to
the more specific.

Yes.

> >       parent zone or matches a trust anchor.

Fred

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 11 Jun 2008 16:50:06 -0700

> tested and the default test order should be from the less specifict to

What do you do when one fails?

If you continue on failure until you find a validating change then  
this is similar to the "OR" that Ray just suggested.. (correct?)

--Olaf

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 11 Jun 2008 20:56:29 -0300

> What do you do when one fails?

Continue with another one more specific until all of them fails.

> this is similar to the "OR" that Ray just suggested.. (correct?)

Yes, it's the OR proposal with a explicit test order.

Fred

---

From: [email-masked]
Date: Thu, 12 Jun 2008 01:20:41 +0100

> Yes, it's the OR proposal with a explicit test order.

Why is the order significant?

Roy

---

From: Niall O'Reilly <[email-masked]>
Date: Thu, 12 Jun 2008 02:33:57 +0100

> validated signature, the validated RRSet is bogus.

	I see ambiguity here, and suggest instead "When NONE of the
	available chains of trust results in a correctly validated
	signature, the validated RRSET is bogus".

	Unless I've completely misunderstood.

	/Niall

---

From: [email-masked]
Date: Thu, 12 Jun 2008 04:13:39 +0000

> 	signature, the validated RRSET is bogus".

	a question for you... you state - "the validated RRSET is
	bogus" - apparently quoting from others. This seems a bit
	incongrus in the context...

	I posit that "When NONE of the available chains reach a 
	configured TA, that the RRSET can not be validated. An
	RRSET that can not be validated can not be presumed to be
	either intact or authentic."

---

From: Niall O'Reilly <[email-masked]>
Date: Thu, 12 Jun 2008 09:27:59 +0100

> incongrus in the context...

	Indeed.
	At that hour of the morning, my focus tends to be narrow.
	8-)

> either intact or authentic."

	Applying 's/TA, that the/TA, the/' would make that (!)
	easier for me to parse.

	[ Rat-hole alert! ]
	Over here, we write "cannot" without a space in the middle.
	IIRC, another Irishman said something about "... two great
	nations, divided by a common language." 8-)

	/Niall

---

From: Frederico A C Neves <[email-masked]>
Date: Thu, 12 Jun 2008 09:45:45 -0300

> Frederico A C Neves wrote on 06/12/2008 12:56:29 AM:
...
> Why is the order significant?

It's not, and this is not a tentative of optimization of the process,
depending on the scenario the selected order could be the
anti-optimization.  The idea is just to put determinism in the
validation behavior.

Fred

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 13 Jun 2008 09:28:30 -0700

>anchors even when there is a valid chain of trust available?

Yes,

>B. If the answer to (A) is, "Yes," what should the default policy be?

All chains of trust are tested and treated as equal.

>trust anchors?

Yes.

--Paul Hoffman, Director
--VPN Consortium