Subject: [dnsext] Proposed addition to dnssec-bis-updates: Nested Trust Anchors

From: "Blacka, David" <[email-masked]>
Date: Mon, 8 Sep 2008 20:58:47 -0400

Folks,

The working group has expressed a desire to clarify what a DNSSEC  
validator should do if more than one trust anchor could be used to  
validate a response.  See the thread starting with http://www.ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00762.html 
.

That thread (to my reading) only terminated with consensus to clarify  
this behavior in dnssec-bis-updates.  It did not, however, come to  
consensus on what that behavior should be.  So, in the interest of re- 
kindling discussion on this issue, I've created (minimal) proposed text:

3.8.  Nested Trust Anchors

    A DNSSEC validator may be configured such that, for a given  
response,
    more than one trust anchor could be used to validate the chain of
    trust to the response zone.  For example, imagine a validor
    configured with trust anchors for "example." and "zone.example."
    When the validator is asked to validate a response to
    "www.sub.zone.example.", either trust anchor could apply.

This paragraph is the same for both solutions.  Solution A is:

    When presented with this situation, DNSSEC validators SHOULD choose
    the trust anchor closest to the QNAME of the response.

Solution B is:

    When presented with this situation, DNSSEC validators SHOULD try all
    applicable trust anchors until one succeeds.

I have no strong opinion as to which solution (or indeed, some other  
solution, if one exists) is documented, but if there is no discussion,  
I will pick solution A, as that is what the current implementations do.

And, of course, any suggestion for improvements to the text are  
appreciated.

--
David Blacka                          <[email-masked]>
Sr. Engineer                   Platform Product Development

--
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: Mark Andrews <[email-masked]>
Date: Tue, 09 Sep 2008 12:23:47 +1000

> validate a response.  See the thread starting with http://www.ops.ietf.org/li
> sts/namedroppers/namedroppers.2008/msg00762.html 
> .
> 

	A as that is what existing configurations do and it is the
	most secure as it doesn't allow TLD's to override end user
	sites trust anchors.

	It's also consistant with the rest of the DNS where the
	child wins at a delegation.

	It also helps with split DNS configuration where you have
	a internal trust anchors which differ from external trust
	anchors for the site and external -> internal leakage will
	be rejected.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 8 Sep 2008 19:47:50 -0700

At 8:58 PM -0400 9/8/08, Blacka, David wrote:
>    A DNSSEC validator may be configured such that, for a given response,

Solution B is preferable when there is no clear semantics to what 
having both "example." and "zone.example." at the same time means. I 
don't seen any clear semantics (I may have missed it), and the 
earlier thread and the off-list discussion made it seem that there is 
wide disagreement on what it means. Therefore, Solution B should be 
the listed.

It is widely expected that zones will continue to add trust anchors 
for top-level zones ("example.") to current DNSSEC implementations, 
and will latter add a root zone ("."). In such a situation, if 
Solution A is defined as correct, when the keys for "example." are 
rolled over, the zone will go bogus. That does not happen with 
Solution B.

In order to help implementers understand why this is a SHOULD instead 
of a MUST, you might want to add:
    There are some scenarios where different actions, such as
    choosing the trust anchor closest to the QNAME of the response,
    could be desired. A DNSSEC validator MAY enable such actions
    as an override to the default action listed above as long as
    the change in action is configurable by the administrator of
    the validator.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 8 Sep 2008 20:28:24 -0700

>	most secure as it doesn't allow TLD's to override end user

Solution A is only "most secure" if define trust anchors in a way 
where they aren't really anchors. If they are really anchors, then 
Solutions A and B have identical security properties. If we want to 
go with Solution A, we need to either stop calling them "trust 
anchors" or come up with something to replace the common-sense 
definition of "trust anchor".

--Paul Hoffman, Director
--VPN Consortium

---

From: Mark Andrews <[email-masked]>
Date: Tue, 09 Sep 2008 13:52:48 +1000

> definition of "trust anchor".

	Solution B is only provides benefit if trust anchors are
	being mis-managed.

	Solution A returns benfit when trust anchors are being
	correctly managed.

	Mark

---

From: Alex Bligh <[email-masked]>
Date: Tue, 09 Sep 2008 08:29:01 +0100

--On 9 September 2008 08:46:02 +0200 Ondřej Surý <[email-masked]> 
wrote:

>   applicable trust anchors from closest to farthest to the QNAME of
>   the response until one succeeds.

Order is irrelevant. B says "does zone.example. or example. or . give
me a secure delegation?". If any one of them gives a secure delegation,
the answer is yes, irrespective of the order in which they are tried.
Why does specifying the order in which they are tried make any
difference? (unless there is some ternary result implied, i.e.
yes, no, don't know so try the next one)

Alex

---

From: Alex Bligh <[email-masked]>
Date: Tue, 09 Sep 2008 08:25:58 +0100

--On 8 September 2008 20:58:47 -0400 "Blacka, David" <[email-masked]> 
wrote:

> solution, if one exists) is documented, but if there is no discussion, I
> will pick solution A, as that is what the current implementations do.

Solution A, as this is far more useful in practice, e.g.
1. zone.example. introduced later, the likely purpose of which would be to
   override existing example. TA
2. zone.example. introduced first, but then example. achieves one (e.g.
   through signing of the root), in which case one would want to continue
   using zone.example. TA until it had been verified resolution would work
   properly with the zone.example. TA removed

I think we should bear in mind nested TAs could be used not only where
 P. (e.g.) . is signed, .com. is not signed, but example.com. is signed
but also where
 Q. (e.g.) . is signed, tld. is signed, but tld. is at . level (re)delegated
    to someone other than whom one wants to resolve against. In this
    scenario, strategy A is far more useful than strategy B.

I'd even go so far as to suggest considering "SHOULD" should read "MUST".

Alex

---

From: [email-masked]
Date: Tue, 9 Sep 2008 07:51:56 +0000

On Tue, Sep 09, 2008 at 08:46:02AM +0200, Ondřej Surý wrote:
> > This paragraph is the same for both solutions.  Solution A is:>>   When presented with this situation, DNSSEC validators SHOULD choose>   the trust anchor closest to the QNAME of the response.>> Solution B is:>>   When presented with this situation, DNSSEC validators SHOULD try all>   applicable trust anchors until one succeeds.
> What about
> Solution C:
>   When presented with this situation, DNSSEC validators SHOULD try all  applicable trust anchors from closest to farthest to the QNAME of  the response until one succeeds.
> But then...  what if there is compromissed key used as trust anchorin resolver configuration?
> Maybe Solution D is the safest:
>   When presented with this situation, DNSSEC validators SHOULD choose  farthest trust anchor from the QNAME of the response.  If there is  no chain of trust between this anchor and the QNAME of the response  DNSSEC validator SHOULD try closer trust anchor and repeat whole  algorithm until the QNAME is validated or there is no more trust  anchors.
> (Please rephrase if necessary
> Ondrej.--  Ondřej Surý technický ředitel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americká 23,120 00 Praha 2,Czech Republic mailto:[email-masked] http://nic.cz/ sip:[email-masked] tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 -----------------------------------------??h?{.n?+???zwZ??,j??v?y?覗???ު笷?)???????"?a{+w?????r??{??jȧ?W??w???^??,j?{[???j?!????m????????_????X????jg???iz??

        let me ask a pragmatic question in an attempt to clarify...

        where will the closest business relationship apply?

        for example.

        mew.isi.edu is the end-node.  mew gets a TA from the ISI.EDU staff (along w/ authorization
                to access internal networks etc...)

                mew also ges a TA from Educause, the current admin for the .EDU zone.
                mew has a free gift from ISC (in the bind distribution) of ICANN's TA for 
                        their(ICANN's) testbed signed root.

        so... which TA is most trustworthy?  ISI's?  EDUCAUSE?  the free gift from ICANN?

	once we get past that question - is there a defautl that -everyone- must use or 
	can the search-order of the TA chain be turned locally?

--bill

---

From: Ralf Weber <[email-masked]>
Date: Tue, 9 Sep 2008 10:02:43 +0200

Moin!

> 	Solution A returns benfit when trust anchors are being
That is exactly the reason why I would opt for Solution B. Operational  
wise there is a lot of mis-management in normal DNS already and with  
the increased complexity of DNSSEC this won't decrease. It is easy to  
create a case where DNSSEC resolution will fail with Solution A, but  
will correctly succeed  with Solution B. Also Solution B IMHO is more  
in line with the robustness principle.

So long
-Ralf
---
Ralf Weber
Platform Infrastructure Manager
Colt Telecom GmbH
Herriotstrasse 4
60528 Frankfurt
Germany
DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780
Fax: +49 (0)69 56606 6280
Email: [email-masked]
http://www.colt.net/

Data | Voice | Managed Services

*****************************************
COLT Telecom GmbH, Herriotstraße 4, 60528 Frankfurt/Main, Deutschland *
Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 *
Geschäftsführer: Albertus Marinus Oosterom (Vors.), Rita Thies *
Amtsgericht Frankfurt/Main HRB 53898 * USt.-IdNr. DE 220 772 475

---

From: "Ondřej Surý" <[email-masked]>
Date: Tue, 9 Sep 2008 11:44:01 +0200

MjAwOC85LzkgQWxleCBCbGlnaCA8YWxleEBhbGV4Lm9yZy51az46Cj4KPgo+IC0tT24gOSBTZXB0ZW1iZXIgMjAwOCAwODo0NjowMiArMDIwMCBPbmTFmWVqIFN1csO9IDxvbmRyZWouc3VyeUBuaWMuY3o+IHdyb3RlOgo+Cj4+ICBXaGVuIHByZXNlbnRlZCB3aXRoIHRoaXMgc2l0dWF0aW9uLCBETlNTRUMgdmFsaWRhdG9ycyBTSE9VTEQgdHJ5IGFsbAo+PiAgYXBwbGljYWJsZSB0cnVzdCBhbmNob3JzIGZyb20gY2xvc2VzdCB0byBmYXJ0aGVzdCB0byB0aGUgUU5BTUUgb2YKPj4gIHRoZSByZXNwb25zZSB1bnRpbCBvbmUgc3VjY2VlZHMuCj4KPiBPcmRlciBpcyBpcnJlbGV2YW50LiBCIHNheXMgImRvZXMgem9uZS5leGFtcGxlLiBvciBleGFtcGxlLiBvciAuIGdpdmUKPiBtZSBhIHNlY3VyZSBkZWxlZ2F0aW9uPyIuIElmIGFueSBvbmUgb2YgdGhlbSBnaXZlcyBhIHNlY3VyZSBkZWxlZ2F0aW9uLAo+IHRoZSBhbnN3ZXIgaXMgeWVzLCBpcnJlc3BlY3RpdmUgb2YgdGhlIG9yZGVyIGluIHdoaWNoIHRoZXkgYXJlIHRyaWVkLgo+IFdoeSBkb2VzIHNwZWNpZnlpbmcgdGhlIG9yZGVyIGluIHdoaWNoIHRoZXkgYXJlIHRyaWVkIG1ha2UgYW55Cj4gZGlmZmVyZW5jZT8gKHVubGVzcyB0aGVyZSBpcyBzb21lIHRlcm5hcnkgcmVzdWx0IGltcGxpZWQsIGkuZS4KPiB5ZXMsIG5vLCBkb24ndCBrbm93IHNvIHRyeSB0aGUgbmV4dCBvbmUpCgpZZXMsIGZyb20gcHVyZSB0ZWNobmljYWwgUE9WIGl0J3MgaXJyZWxldmFudC4gIEJ1dCBpZiB5b3UgZGVmaW5lIGxvb2t1cCBvcmRlcgppdCBnaXZlcyB5b3Ugc29tZSBhZHZhbnRhZ2VzOgoKMS4gaWYgeW91IGdvIGZyb20gdGhlIGNsb3Nlc3QgdG8gdGhlIGZhcnRoZXN0IC0geW91IHByZXZlbnQgdXNlbGVzcyBEUyBsb29rdXBzCjIuIGl0J3MgYWx3YXlzIGJldHRlciB0byBjbGVhcmx5IGRlZmluZSBhbGdvcml0aG0gdXNlZCwgc28gaW1wbGVtZW50b3JzIGRvIGl0CiAgIHNhbWUgd2F5IC0gaXQncyBtdWNoIGVhc2llciB0byBkZWJ1Zy4KCk9uZHJlai4KLS0gCiBPbmTFmWVqIFN1csO9CiB0ZWNobmlja8O9IMWZZWRpdGVsL0NoaWVmIFRlY2huaWNhbCBPZmZpY2VyCiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQogQ1ouTklDLCB6LnMucC5vLiAtLSAuY3ogZG9tYWluIHJlZ2lzdHJ5CiBBbWVyaWNrw6EgMjMsMTIwIDAwIFByYWhhIDIsQ3plY2ggUmVwdWJsaWMKIG1haWx0bzpvbmRyZWouc3VyeUBuaWMuY3ogaHR0cDovL25pYy5jei8KIHNpcDpvbmRyZWouc3VyeUBuaWMuY3ogdGVsOis0MjAuMjIyNzQ1MTEwCiBtb2I6KzQyMC43MzkwMTM2OTkgZmF4Ois0MjAuMjIyNzQ1MTEyCiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo=--to unsubscribe send a message to [email-masked] withthe word 'unsubscribe' in a single line as the message text body.archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 09 Sep 2008 11:43:50 +0200

Ondřej Surý wrote:
>   farthest trust anchor from the QNAME of the response.  If there is
>   no chain of trust between this anchor and the QNAME of the response
>   DNSSEC validator SHOULD try closer trust anchor and repeat whole
>   algorithm until the QNAME is validated or there is no more trust
>   anchors.

I think this is already in the current RFC 4035 (p27):

 "If the validator authenticates an NSEC RRset that proves that no DS
  RRset is present for this zone, then there is no authentication path
  leading from the parent to the child.  If the resolver has an initial
  DNSKEY or DS RR that belongs to the child zone or to any delegation
  below the child zone, this initial DNSKEY or DS RR MAY be used to
  re-establish an authentication path."

But instead of SHOULD, it says MAY. And it does not say anything about
trying the farthest first.

Matthijs

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 09 Sep 2008 11:53:06 +0200

Paul Hoffman wrote:
> Solution A is only "most secure" if define trust anchors in a way where
> they aren't really anchors. If they are really anchors, then Solutions A
> and B have identical security properties. If we want to go with Solution
> A, we need to either stop calling them "trust anchors" or come up with
> something to replace the common-sense definition of "trust anchor".

It is called a trust anchor, because it is configured at the resolver.
In other words, the resolver puts its trust in this data. If it is badly
maintained, than imo it's the resolver's responsibility.

Quoting Mark Andrews:

For robustness reasons, I'm in favor of solution B. I also believe that
Solution A should be configurable. By the way, if trust anchors are
being correctly managed, we wouldn't have this discussion ;)

Matthijs

---

From: Mark Andrews <[email-masked]>
Date: Tue, 09 Sep 2008 19:56:15 +1000

In message <[email-masked]>, Ralf Weber writ
es:
> That is exactly the reason why I would opt for Solution B. Operational =20=
> 
> wise there is a lot of mis-management in normal DNS already and with =20
> the increased complexity of DNSSEC this won't decrease. It is easy to =20=
> 
> create a case where DNSSEC resolution will fail with Solution A, but =20
> will correctly succeed  with Solution B. Also Solution B IMHO is more =20=
> 

	And in the end people will just configure a trust anchor
	for "." and their own zones which they won't want to be
	overridden by chains of trust from the root.

	B only has short term advantages.

> COLT Telecom GmbH, Herriotstra=DFe 4, 60528 Frankfurt/Main, Deutschland =
> *
> Gesch=E4ftsf=FChrer: Albertus Marinus Oosterom (Vors.), Rita Thies *

---

From: "Ondřej Surý" <[email-masked]>
Date: Tue, 9 Sep 2008 12:01:17 +0200

2008/9/9  <[email-masked]>:
>        once we get past that question - is there a default that -everyone- must use or

It almost seems to me that we need something like TA priority.  So
end-node can override
default priorities.

And let's not forget things get even more complicated when RFC 5011 is
taken into account.

edu publishes new key B (DS) for isi.edu.

isi.edu sets revocation bit on A and signs isi.edu using B.

mew.isi.edu has TA for edu and for isi.edu (key A).

What happens in these various scenarios we are discussing?

Ondrej.
-- 
 Ondřej Surý
 technický ředitel/Chief Technical Officer
 -----------------------------------------
 CZ.NIC, z.s.p.o. -- .cz domain registry
 Americká 23,120 00 Praha 2,Czech Republic
 mailto:[email-masked] http://nic.cz/
 sip:[email-masked] tel:+420.222745110
 mob:+420.739013699 fax:+420.222745112
 -----------------------------------------
h�{.n�+���zwZ��,j��v�y�覗������-��"z��"�a{
+v�칻�&ފv��x%zX�y�-�鞲Ơzױ��ɪ܆+ކ�i��)�'�~���X����jg���iz�?

---

From: Florian Weimer <[email-masked]>
Date: Tue, 09 Sep 2008 12:11:00 +0200

> 	most secure as it doesn't allow TLD's to override end user

It's more secure only if you discount availability.  Option B is
better if you need to change the keys even if some trust anchors are
still deployed.

However, I think option A is the preferred behavior if you want to
guard against loss of administrative control of your zone (or their
parents).

But I still think option B has some value for trust anchors which
cross administrative boundaries.

> 	child wins at a delegation.

To some extent, I'm a bit surprised that this is considered part of
the protocol.  Isn't it more like a local policy decision?

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Alex Bligh <[email-masked]>
Date: Tue, 09 Sep 2008 11:47:50 +0100

> the protocol.  Isn't it more like a local policy decision?

Thinking about it, a server providing a knob to set TA priority would
be fine, and I withdraw my earlier comment re consider "MUST".

Alex

---

From: Scott Rose <[email-masked]>
Date: Tue, 9 Sep 2008 07:06:53 -0400

I think Bill's comment (while not strictly technical) will be the  
deciding factor to most organizations.  People/Orgs place levels of  
trust on things.

Option B sounds the best, but also has the problem if the parent trust  
anchor (example. ) fails to properly roll over their key (failed to  
follow RFC 5011, etc.).  In which case the validator would be correct  
to follow option A.

Some sort of prioritizing a key (via local policy) might be ideal,  
then pick one (I would support Option B)  - or-  add "unless there is  
a trust anchor installed that exactly matches the signer's name in the  
RRSIG in the response" or similar.

Scott

> 	can the search-order of the TA chain be turned locally?

===================================
Scott Rose
NIST
[email-masked]
ph: +1 301-975-8439
http://www-x.antd.nist.gov/dnssec
http://www.dnsops.gov/
===================================

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 09 Sep 2008 13:21:57 +0200

Ondřej Surý wrote:
> As I understand it this whole thread is exactly about order and number
> of keys used.

Yes, and I wanted to notify that the RFC already describes order in some
extent.

Matthijs

---

From: Antibozo <[email-masked]>
Date: Tue, 09 Sep 2008 04:21:54 +0000

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

> something to replace the common-sense definition of "trust anchor".

I don't follow. What about overriding the trust anchor for a particular
zone is at odds with the "common-sense definition" of "trust anchor"?
Why is such an anchor "not an anchor"? Seems to me if a valid chain
terminates on it, it's an anchor.

-- 
Jefferson Ogata : Internetworker, Antibozo

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 9 Sep 2008 08:52:50 -0400

Hi,

> will pick solution A, as that is what the current implementations do.

I have a question about these alternatives.  Given the following text
in RFC 4035

   To use DNSSEC RRs for authentication, a security-aware resolver
   requires configured knowledge of at least one authenticated DNSKEY or
   DS RR.  The process for obtaining and authenticating this initial
   trust anchor is achieved via some external mechanism. 
[. . .]

   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.

does either one of the proposed options change the meaning of that
RFC?  Please note that I am _not_ asking, in this question, which
option is the right one.  I'm just asking whether people think that
the current implementations conform with the RFC text as it currently
stands.

A

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

---

From: [email-masked]
Date: Tue, 9 Sep 2008 14:22:34 +0100

> the current implementations conform with the RFC text as it currently

Personally I believe that option (B) is completely consistent with the 
RFC, and that option (A) is not.

Ray

-- 
Ray Bellis, MA(Oxon)
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: Frederico A C Neves <[email-masked]>
Date: Tue, 9 Sep 2008 10:32:03 -0300

> the current implementations conform with the RFC text as it currently

Definitely not. The spec is crystal clear. The current implementations
(AFAIK besides dig sigchase) that doesn't follow all the TAs violate
it.

> A

Fred

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 9 Sep 2008 08:34:47 -0700

>zone is at odds with the "common-sense definition" of "trust anchor"?

In the common-sense definition, one cannot "override" a trust anchor.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 9 Sep 2008 08:33:12 -0700

>	Solution B is only provides benefit if trust anchors are

True. And Solution A fails horribly when trust anchors are being 
mismanaged. That seems like a good enough argument to go with 
Solution B as long as there is wording that allows Solution A (or 
something like it) to be configurable as the non-default solution.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 9 Sep 2008 08:39:23 -0700

>	overridden by chains of trust from the root.

Probably true for a small number of users. Those users can then 
choose the non-default action in their resolver.

--Paul Hoffman, Director
--VPN Consortium

---

From: Jefferson Ogata <[email-masked]>
Date: Tue, 09 Sep 2008 16:14:40 +0000

> In the common-sense definition, one cannot "override" a trust anchor.

Repeating your claim does not an argument make. What is this
"common-sense" definition you have in mind, exactly?

It's a "trust anchor" if it's an anchor--i.e. the terminus of a
validation chain, and I choose to trust it. That's common sense, AFAIC.

Analogously, in an X.509 scenario, I might choose to replace a CA
certificate on a system I control with my own version under the same
issuer name, in order to be able to sign certificates under the guise of
that issuer for my local validators, i.e. overriding a trust anchor with
a different trust anchor. I might do this in order to pen-test some
software that requires a particular issuer's certificate. There is no
reason I wouldn't call my version of the CA certificate a "trust
anchor". Whether something is a trust anchor is a function of how you
use it.

Solution B also allows override, since it iterates over all the
applicable trust anchors until one succeeds. So I really don't
understand your point.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 9 Sep 2008 10:08:43 -0700

>validation chain, and I choose to trust it. That's common sense, AFAIC.

Yep; fully agree.

>anchor".

Correct. But that is different than "overriding" other trust anchors. 
It is simply adding another. See below.

>Whether something is a trust anchor is a function of how you
>use it.

Definitely.

>applicable trust anchors until one succeeds.

That is not overriding any of them. In Solution B (which is what is 
also expressed in RFC 4035), if you have trust anchors X and Y, and 
the validation check fails with X, you try Y. Trying Y does not 
override X, it adds another path to check.

We may be viewing the goal differently. It seems like your goal is 
"If I have a trust anchor that fails, find it first and don't trust 
the signature" (call that Goal F). I think most other people are 
using the goal "If I have a trust anchor that succeeds, find it and 
trust the signature" (call that Goal P). My reading of RFC 4035 is 
that it is strongly based around Goal P, but it allows configuring a 
system for Goal F.

--Paul Hoffman, Director
--VPN Consortium

---

From: [email-masked]
Date: Tue, 9 Sep 2008 17:33:42 +0000

On Tue, Sep 09, 2008 at 12:01:17PM +0200, Ondřej Surý wrote:
> 2008/9/9  <[email-masked]>:> On Tue, Sep 09, 2008 at 08:46:02AM +0200, Ondřej Surý wrote:>> > This paragraph is the same for both solutions.  Solution A is:>>   When presented with this situation, DNSSEC validators SHOULD choose>   the trust anchor closest to the QNAME of the response.>> Solution B is:>>   When presented with this situation, DNSSEC validators SHOULD try all>   applicable trust anchors until one succeeds.>> What about>> Solution C:>>   When presented with this situation, DNSSEC validators SHOULD try all  applicable trust anchors from closest to farthest to the QNAME of  the response until one succeeds.>> But then...  what if there is compromissed key used as trust anchorin resolver configuration?>> Maybe Solution D is the safest:>>   When presented with this situation, DNSSEC validators SHOULD choose  farthest trust anchor from the QNAME of the response.  If there is  no chain of trust between this anchor and the QNAME of the response  DNSSEC validator SHOULD try closer trust anchor and repeat whole  algorithm until the QNAME is validated or there is no more trust  anchors.>> (Please rephrase if necessary>>        let me ask a pragmatic question in an attempt to clarify...>>        where will the closest business relationship apply?>>        for example.>>        mew.isi.edu is the end-node.  mew gets a TA from the ISI.EDU staff (along w/ authorization>                to access internal networks etc...)>>                mew also ges a TA from Educause, the current admin for the .EDU zone.>                mew has a free gift from ISC (in the bind distribution) of ICANN's TA for>                        their(ICANN's) testbed signed root.>>        so... which TA is most trustworthy?  ISI's?  EDUCAUSE?  the free gift from ICANN?>>        once we get past that question - is there a default that -everyone- must use or>        can the search-order of the TA chain be turned locally?
> It almost seems to me that we need something like TA priority.  Soend-node can overridedefault priorities.
> 
> 
> 
> And let's not forget things get even more complicated when RFC 5011 istaken into account.

	this will only happen when isi.edu has already generated new DS rr.
	and when that happens, isi.edu will distribute "B" to mew.isi.edu
	(hopefully before .edu has the new DS installed/signed

> Ondrej.--  Ondřej Surý technický ředitel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americká 23,120 00 Praha 2,Czech Republic mailto:[email-masked] http://nic.cz/ sip:[email-masked] tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 -----------------------------------------

---

From: Florian Weimer <[email-masked]>
Date: Wed, 10 Sep 2008 09:13:11 +0200

> RFC, and that option (A) is not.

I agree.  And making A consistent requires edits beyond the parts
Andrew quoted.

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 10 Sep 2008 14:52:25 -0700

>>>>> On Mon, 8 Sep 2008 20:58:47 -0400, "Blacka, David" <[email-masked]> said:

DB> This paragraph is the same for both solutions.  Solution A is:

DB> When presented with this situation, DNSSEC validators SHOULD choose
DB> the trust anchor closest to the QNAME of the response.

DB> Solution B is:

DB> When presented with this situation, DNSSEC validators SHOULD try all
DB> applicable trust anchors until one succeeds.

Having followed the discussion to date I think a few points haven't been
brought up that are probably important:

1) Considering trust anchors for:

   example.com.
   sub.example.com.

   There aren't a huge number of cases where the two would be both put
   into a trust anchor list.  The two most likely that have been
   mentioned are:

   a) Deliberate for trust reasons: sub.example.com is expected to be
      preferred over example.com

   b) Accidental: either one or the other (most likely example.com) was
      added later, most likely because of increasing deployment of
      DNSSEC.

   Because Solution (B) provides greater protection against broken
   networks, I'm of the opinion that should be preferred.  And I write
   that with an added note that until 5 minutes before writing this I
   was of the opposite opinion.

   What changed my mind was the "deliberate intent" that must go into
   (a) above.  If someone is deliberately intending to prefer one over
   the other, and they're modifying their configuration to accomplish
   this then I'm hoping they're smart enough to make intelligent
   decisions surrounding trust levels.  Because of this, I assume they
   have the intelligence to turn on the policy knob that says "prefer"
   vs the default of "use any".  IE, if they're doing something with
   deliberate intent then doing something else with the same intent
   isn't a big jump for them and putting the burden on them doesn't
   worry me.

   On the other hand, (b) is likely to result from someone with less,
   um, "skill".  IE, an accident.  Or maybe because they deliberately
   wanted redundancy.  Either way, it's obviously beneficial (as has
   been stated) to have multiple paths since they don't care about
   policy.  The only exception would be people that blew my intelligence
   test from the previous sentence; but again, I'm not as worried about
   them as I am worried about the less-knowledgeable segment of the
   world that just wants a secure network but doesn't understand the
   complexity of the protocol (and I doubt they're trying to set policy).

2) Configuration exposure: As long as we're talking about policy
   wording, I'd like to suggest adding something like: "implementations
   SHOULD provide configuration settings to select between supporting
   and not supporting trust anchor preference".

3) Another, not yet discussed, down side of (B) is the greater resources
   hit.  If the sub.example.com trust anchor is misconfigured (or stale)
   but the example.com trust anchor is valid, deployed validators will
   spend a lot of time (CPU) validating against sub.example.com and
   falling back automatically to example.com and it's likely an
   administrator will never know about their resource loss.  A SHOULD
   log the failure of a more specific trust anchor might be worth adding
   because of this.

   (This being said, it's not a big enough concern as to draw be back to
   preferring (A) even though it's a mark against it.)

4) DLV (RFC5074 which is at INFORMATIONAL).  It hasn't been mentioned
   yet, but it's possible with DLV to have the following trust anchors:

   dlv1.org
   dlv2.org
   example.com.
   sub.example.com.

   The DLV document actually discuss this issue in depth in section 7
   and is worth reading and it actually states implementation-decision.
   Note with DLV that there isn't even a way to select which one of the
   dlv trees is "closer".  RFC5074 *does* however state that
   implementations SHOULD expose a configuration option, which backs up
   my request to do so in this case.

   Also interestingly, RFC5074 sort of proposes a default but doesn't
   put it into MAY/SHOULD/MUST wording as is more of a side comment:

     "As a very simple default, a validator could give precedence to the
     most specific DLV domain."

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

---

From: Peter Koch <[email-masked]>
Date: Mon, 15 Sep 2008 12:44:17 +0200

FWIW, I'd also support option (B) as a default, because it prefers the rule
("TA"s within the DNS) over the exception (TAs externally supplied).
However,

>    and not supporting trust anchor preference".

if for some reason someone _really_ wants a particular TA to prevail no matter
what other trust chains within or out of the DNS suggest, so be it.
That should be an attribute to a TA ("MUST NOT be overridden by parent").
A MAY would suffice, though, IMHO.

There's one operational issue that I think Bill already mentioned:
Usually you'd not want the resolution of your "own" domain name depend
on external resolution, i.e. from an organization using "example.org", you'd
make sure your externally facing resolvers eiterh have authoritative stealth
copies of example.org or support "forwarding zones" or similar mechanisms.
The same holds for the DNSKEY of the example.org zone then.
That's not an argument against (B), but it calls for a defined order of TAs.

-Peter