Subject: [dnsext] Nested trust anchors (again)

From: Matt Larson <[email-masked]>
Date: Tue, 23 Jun 2009 10:33:36 -0400

There's a thread on the DNS-OARC dns-operations list
<[email-masked]> that is really a protocol issue, so
I'm bringing it up here.  The subject is, once again, how a validator
should behave in the presence of multiple trust anchors.

BIND prefers the closest trust anchor to the QNAME, while the latest
version of the dnssec-bis-updates draft calls for trying all trust
anchors until one succeeds.  The draft also calls for a configurable
option to enable favoring the closest trust anchor to the QNAME.
Please see:

http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-08#section-4.8

This text was based on a namedroppers thread from early September 2008
entitled "Proposed addition to dnssec-bis-updates: Nested Trust
Anchors".  By my (and the dnssec-bis-editors') reckoning, "try all
trust anchors" was overwhelmingly the preferred option.  (I just
re-read the entire thread.)

Now, of course, dnssec-bis-updates isn't final, but last September's
discussion looks pretty clear to me.  Since we are apparently still
discussing this topic, I wanted to point out the nested trust anchor
text in dnssec-bis-updates so there are no surprises at last call.

It would sure be nice to see BIND change its default behavior to "try
all trust anchors" and make "trust the closest trust anchor" a
configurable option.

Matt

----- Forwarded message from Mark Andrews <[email-masked]> -----

From: Mark Andrews <[email-masked]>
Subject: Re: [dns-operations] .Org DNSSEC key management policy feedback
To: Roy Arends <[email-masked]>
Cc: [email-masked]
Date: Tue, 23 Jun 2009 12:18:14 +1000

In message <[email-masked]>, Roy Arends writes:
> On Jun 23, 2009, at 9:39 AM, Mark Andrews wrote:
> 
> >
> > In message <[email-masked]>, Roy  
> > Arends writes:
> >> On Jun 23, 2009, at 3:11 AM, Andrew Sullivan wrote:
> >>
> >>> On Sun, Jun 21, 2009 at 03:24:20PM +0000, [email-masked]
> >>> wrote:
> >>>> On Sun, Jun 21, 2009 at 07:50:47AM -0700, David Conrad wrote:
> >>>
> >>>>> Yes, but until the root is signed, people will still need to  
> >>>>> update
> >>>>> their trust anchors to reflect all the islands of trust, including
> >>>>> the
> >>>>> TLDs, they want to validated.
> >>>
> >>>> 	even then, they might want to keep the .ORG key
> >>>
> >>> I'm rather hoping not.  Given the way BIND prefers the "closest"
> >>> configured trust anchor, I think it will make things less reliable.
> >>> Suppose people decide to keep their existing .org key, and then the
> >>> root is signed, and the key-keepers think, "Good," and stop checking
> >>> for updates.  On the next .org key-roll, all of .org instantly goes
> >>> dark for those people with the stale key.
> >>
> >> That still hasn't been fixed?  It seems wrong and very annoying. In  
> >> my
> >> end user experience, it violates the principle of least astonishment.
> >
> > 	Actually it doesn't.  If you configure a trust-anchor for
> > 	your own company you don't want anything overriding it.
> > 	Having that overridden would be POLA violation.
> >
> > 	Having things break because you stopped managing/tracking
> > 	them is not a POLA violation.
> 
> That is a niche kind of market. It would be nice if this behavior  
> would be configurable, but should not be the default. You seem to be  
> under the impression that this behavior is standardized in some  
> protocol specification, and thus should be the default.

	It is the default for BIND.  It has been for 10 years now.
	Changing the default policy in BIND would be POLA violation.
 
> >> I remember the main counter argument was that folks might want to
> >> configure the .ORG key for everything in and under .ORG, and not  
> >> trust
> >> the root key for .ORG, but do trust the root key for everything else.
> >> Doesn't fly. There might be simple dependencies from domains under  
> >> ORG
> >> on something not ORG. See for instance http://www.links.org/?p=635 on
> >> "who pwns the internet".
> >
> > 	For . and ORG I agree.  For ORG and ISC.ORG I disagree.
> > 	For wattle.id.au (when it is signed) and andrews.wattlet.id.au
> > 	I disagree.  There are couple of hundred zones where your
> > 	policy makes sense.  There are millions where named's default
> > 	policy will make sense.
> 
> Imagine I have configured a key for au and for net.au. The latter key  
> is not updated. Whoops, there goes id.au.

	If you stuff up key management things go wrong.

> > 	Your policy model make sense if you *start* doing DNSSEC
> > 	during the bottom up development phase.
> 
> That is, imho, the phase we're getting into.

	And I'm writing code that will still be in use 10 years
	down the track.  You want a default policy that will be out
	of date in 7 months for ORG.  ORG will be in top-down by
	the end of the year.  COM a little longer but not much.
 
> >  If you start in
> > 	the top down phase it doesn't and top down is the long term
> > 	status.
> 
> By that time, this policy should be configurable, and eventually, the  
> default can be changed on behalf on market demand.

	People need "trust the closest trust anchor only" policy now.

	People will never need "use any possible trust anchor" policy.
	It might be nice to have but it will never be a needed policy.

	Mark
 
> Kind regards,
> Roy
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
dns-operations mailing list
[email-masked]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

----- End forwarded message -----

--
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: Edward Lewis <[email-masked]>
Date: Tue, 23 Jun 2009 13:04:37 -0400

>re-read the entire thread.)

I haven't re-read the thread but for the sake of robustness, trying 
any possible way to validate data is a good thing.  OTOH, an 
implementation should make sure that the user is aware if they have 
nested trust anchors, in an effort to limit stale anchors inviting 
attacks using past private keys gone public.

>all trust anchors" and make "trust the closest trust anchor" a

With the caveat that this WG isn't the right vehicle to bring about 
change in a specific implementation, and trying to generalize my 
recommendation:

A validator should try all possible trust anchors and try all 
possible signature chains to find one that "works."  At this point 
the answer should be considered valid.  Recall that the bar in DNSSEC 
isn't the accuracy of the data but the accuracy of the delivery of 
the data.

A trusted anchor module should make every attempt to limit the 
presence of stale data hanging around.  This is weasel-ly worded 
because I don't have a clear mechanism for this in my own head. 
Perhaps this means 5011 support or something like root zone hints 
priming.  (Yadda, yadda, yadda...)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Thu, 25 Jun 2009 14:08:42 +0200

Hi,

>> re-read the entire thread.)

I oppose the 'try all anchors'.  Current bind choice to apply the
closest is the most sensible one, because a higher trust anchor is not
particularly more trusted.  Probably less trusted, since it has a
broader scope.  If a user enters a trust anchor, it decides it wants to
trust *that* anchor.  Like in any configuration, the narrower the scope,
the more relevant the information.

I want the text in dnssec-bis-updates to be changed to say it should try
the closest set of trust anchors.  Best is to remove the text, it is all
about configuration which is probably not really important once the
'many islands' DNSSEC turns into a root signed DNSSEC.

What I saw was a lot of people chiming into, like Ed's below, 'trying
more is more robust'.  However, it is less secure.  The point is to have
trust in the anchor.  Trying more is also unlikely to work, since the
operator added this lower (non-working) anchor, the global-root-chain of
trust is unlikely to work, or if it works, be trusted.

Mostly people responded with 'but if the root is signed and the
operators forgets his configured trust anchor ...'.   Well the operator
of course has automated trust-anchor tracking on that anchor, so it
should be no problem.  And every trust anchor without proper update
mechanisms is going to be outofdate anyway.  Going to the root only
creates a security problem in this space, and does not solve anything.

So, I want to reiterate my position that I think this creates a surprise
in configuration.  And a security related one at that.

> I haven't re-read the thread but for the sake of robustness, trying any
> possible way to validate data is a good thing.  OTOH, an implementation
> should make sure that the user is aware if they have nested trust
> anchors, in an effort to limit stale anchors inviting attacks using past
> private keys gone public.
> 

No, it should not.  Plans are to have the root signed. Once that is done
this is most likely the higher trust anchor.  If a user configures a
lower trust anchor, most likely this is when the user wants something
specific for (his own company, or his own country, his own military,
...).  And that user does not trust 'he who holds the root key'.

Of course, users probably won't be configuring trust anchors, except the
root, anyway.  Unless it is an entirely local matter, in which case
trying the global roots won't help.

> A validator should try all possible trust anchors and try all possible
> signature chains to find one that "works."  At this point the answer
> should be considered valid.  Recall that the bar in DNSSEC isn't the
> accuracy of the data but the accuracy of the delivery of the data.
> 
> A trusted anchor module should make every attempt to limit the presence
> of stale data hanging around.  This is weasel-ly worded because I don't
> have a clear mechanism for this in my own head. Perhaps this means 5011
> support or something like root zone hints priming.  (Yadda, yadda,
> yadda...)

Please explain to me again why this is needed and should be in
dnssec-updates?

Best regards,
   Wouter

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 25 Jun 2009 14:30:13 +0200

On Tue, Jun 23, 2009 at 10:33:36AM -0400,
 Matt Larson <[email-masked]> wrote 
 a message of 149 lines which said:

> the latest version of the dnssec-bis-updates draft calls for trying
> all trust anchors until one succeeds.  The draft also calls for a
> configurable option to enable favoring the closest trust anchor to
> the QNAME.

Without discussing of the ideal default option, I would like the draft
to mention other possible policies as well. I can see at least four,
and IMHO, there is an use case for each of them:

* ANY trust-anchor which works (the current default policy in
dnssec-bis-updates)

* ALL the trust-anchors must work (highly secure, for the truly
paranoids)

* The CLOSEST trust-anchor must work (if I configure a local
trust-anchor, it is because I know what I do)

* The HIGHEST trust-anchor must work (the root trust anchor will
probably be less stale than local ones).

---

From: Edward Lewis <[email-masked]>
Date: Thu, 25 Jun 2009 09:33:30 -0400

>Please explain to me again why this is needed and should be in

This is an open-ended question.  I'll ramble on for Wouter to see is 
this lays any ideas.   Perhaps it is too wide ranging for general 
consumption.

The issue begins with understanding the difference between a 
distributed system that has a "closed population" and an "open 
population."  In the former, the entire system can stay into the 
territory of closely coupled fairly easily.  In the latter, loose 
coupling is what can be achieved.  This lies in the fact that in a 
closed system it is possible to know you have polled all participants 
and are able to delineate a sequence of events, something important 
when scheduling access to a critical resource.  In an open system the 
problem becomes undecidable because you can never know what the real 
sequence of events is.  (Einstein's Special Theory of Relativity 
actually applies to this.)

With the Internet, particularly the DNS protocol within it, being an 
open system, the coupling of the system will be loose.  The 
consequence of trying to tighten up the system will merely cause 
cracks in the system near where you tighten it.  How does this 
theoretical hand waving play here?

There are too many actors involved to ever attain coherent (and 
unanimous) consensus on what is "trust."  In truth there is no "bad 
guys" just "guys with different goals that you and their goals are 
not compatible with yours."  Not everyone in the DNS wants the same 
security, they all do want security - for their interests.  If we try 
to establish a "one true secure system" will will be in a morass, 
like the issue of trying to sign the root now.

The reason the DNS (system) has become the monster it is lies in it's 
laid back nature regarding coordination in managing the pieces.  If 
you think it is bad that the delegation points are so "weak" in the 
sense that we have glue issues, what you are missing is that the 
loose coupling there is how the system was able to scale beyond the 
borders of the IETF.  The DNS architecture's success is a result of 
it embracing the nature of an open population distributed system. 
DNSSEC could have reversed that embrace but in doing so would have 
killed off DNSSEC.

The next factor is that the addition of security to any existing 
system innately injures the stability and availability of the system 
to some extent.  False positives, as it sometimes called.  This 
concept was described to me as "imagine a state machine" describing a 
system.  There are states which are "safe" and states that are 
vulnerable.  There is a third set of states which are "at risk."  At 
risk states are those in which some transitions out land in safe 
states and some transitions out land in vulnerable states.  The goal 
of a security system is to prevent the system from winding up in the 
vulnerable states, but this usually means that at risk states are 
also prevented.  The "false positive" here is a path from a safe to 
"at risk" to safe that is blocked (unnecessarily).  Like a homeowner 
who's locked out of their own house.

In DNSSEC, if you tighten the search for a trust anchor you will be 
cutting off at risk states.  You will be denying (DNS response) data 
that could be good, the consequence is a support call.  Harking back 
to the closed vs. open population, the bad part of a support call is 
not simply that it costs money to the handler, it's that the support 
call will go to the wrong entity.  It will likely go to the ISP or IT 
department, the folks least likely to be able to correct the problem 
(assuming they understand DNSSEC) - at best.

The final factor in trying all possible means is the operational rule 
that data statically stored anywhere is going to lead to problems 
eventually.  Again, harking back to issue one, operators live in a 
open population environment.  It is not possible to reliably do 
something "static" and have it go away on cue.  I have seen static 
configurations go away - usually during an audit.  But by and large, 
static data gets forgotten. Worse yet - forgotten in a way that means 
it is impossible to locate or remember that it is present.

I don't know if Olafur recalls this, but at UMD he did a study of 
traffic on the department's Ethernet cable network.  They observed a 
pattern of traffic that was causing low layer issues but it came from 
an unidentified source.  Eventually someone found the device and 
unplugged it and the issue went away.  One day the pattern returned - 
for some reason the location of the box had been forgotten by the 
network monitoring staff although it was known by - possibly a 
janitor who put the plug back in to the wall.

Things like that happen.  I picked that example because it is the 
earliest one I know personally.  (My job these days is to remember 
all of the places "static" data and ideas went.)  In the 80's it was 
equipment on a wire.  Nowadays it is items in a configuration/start 
up script.  Unless you are a Unix-like system admin, the amount of 
configuration data out there is just too dang much to track.

The summary of this is, DNSSEC's trust model is going to be one that 
has flexibility to adapt to the demands of a diverse and open 
population.  By the nature of being a security system, DNSSEC is 
crimping the actions of the base system, and to remain useful to the 
original system, has to try hard "to get the mail through."  Finally, 
most configured trust anchors will be stale at any given time.

PS - It's essential we try all ways to get the data through.  It 
would be a "really good idea" if any validator that has to fall back 
to another anchor makes this action known to somebody who can take an 
action on that.

Come to think of this, it's a lot like the debate over EDNS0 fallbacks.

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Thu, 25 Jun 2009 16:06:41 +0200

On 06/25/2009 03:33 PM, Edward Lewis wrote:
> The summary of this is, DNSSEC's trust model is going to be one that has
> flexibility to adapt to the demands of a diverse and open population. 
> By the nature of being a security system, DNSSEC is crimping the actions
> of the base system, and to remain useful to the original system, has to
> try hard "to get the mail through."  Finally, most configured trust
> anchors will be stale at any given time.

Thanks, I agree with the theory.  So, I change my position, agree with
dnssec-updates, and am now thinking about options for trust anchors -
what Stephane is talking about.

> PS - It's essential we try all ways to get the data through.  It would
> be a "really good idea" if any validator that has to fall back to
> another anchor makes this action known to somebody who can take an
> action on that.

Yes some warning, since the operator supplied the static data, its fine
to inform him about it.  Its not like trying to tell operators about
every lame server on the internet :-)

> Come to think of this, it's a lot like the debate over EDNS0 fallbacks.

And nail in the coffin for all those TCP, PING, 0x20 and also my own
forgery resilience options, in that they should really support all
fallbacks to make it work.  But they cannot provide their security to
all the domains, as they are too loosely coupled to be amenable.

Best regards,
   Wouter

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 25 Jun 2009 07:22:02 -0700

At 2:08 PM +0200 6/25/09, W.C.A. Wijngaards wrote:
>I oppose the 'try all anchors'. 

Please pardon me for being blunt, but this is not about what *you* want in your system, it is about what would be best for the Internet as a whole. You might want "try closest", and the current document says that should be available.

The assumption that you (and BIND) make is that someone has carefully thought out the effects of each individual trust anchor in the root pile. That is clearly a wrong assumption when considering the Internet as a whole. The example that generated this discussion is still relevant. In time order:

- Trust anchor for example.sub is added
- Later, trust anchor for example is added
- The maintainer for example.sub rolls the key and does the right thing with its parent
- You and BIND see example.sub go bogus because you didn't remove the "closer" trust anchor

You might want that to happen based on a policy that says you will always calculate the relationships between every trust anchor. Some of us don't want that to be the default on the Internet because we believe that DNS admins will not be so careful, and the effect is that zones go bogus *even though the resolver has the right information*.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Vixie <[email-masked]>
Date: Thu, 25 Jun 2009 15:24:39 +0000

> Date: Thu, 25 Jun 2009 14:30:13 +0200
> From: Stephane Bortzmeyer <[email-masked]>
> 

+1.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 26 Jun 2009 01:55:09 +1000

In message <p06240801c66936cdcabd@[10.20.30.249]>, Paul Hoffman writes:
> Please pardon me for being blunt, but this is not about what *you* want in yo
> ur system, it is about what would be best for the Internet as a whole. You mi
> ght want "try closest", and the current document says that should be availabl
> e.
> 
> The assumption that you (and BIND) make is that someone has carefully thought
>  out the effects of each individual trust anchor in the root pile. That is cl
> early a wrong assumption when considering the Internet as a whole. The exampl
> e that generated this discussion is still relevant. In time order:
> 

	Which is why you don't add trust anchors willy nilly.  You
	add trust anchors for zones that publish trust anchors not
	every zone that is signed.  That way key rollover takes
	into account validators that have the trust anchor configured.

	Note the above senario is the result of the current bottom
	up deployement growth.  Once the root is signed we will see
	more and more top down deployment where you don't need all
	the extra trust anchors.

	One really should mimimise the numbers of trust achors you
	have.
 
> You might want that to happen based on a policy that says you will always cal
> culate the relationships between every trust anchor. Some of us don't want th
> at to be the default on the Internet because we believe that DNS admins will 
> not be so careful, and the effect is that zones go bogus *even though the res
> olver has the right information*.

	And you haven't thought out the other senarios where jumping
	over trust anchors is bad.  There are lots of configurations
	where jumping over a trust anchor is a waste of time.

	You want to make a mis-managed trust anchor not be a problem.

	You want to force implementations that made decisions 10
	years ago to change default policy for no good reason.
	Decisions that are as valid today as they were then.

	There are configurations where you want trust paths from
	higher up to fail because it they succeed there would have
	been a information leak.

	Mark

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 25 Jun 2009 16:02:46 -0400

On Thu, Jun 25, 2009 at 02:08:42PM +0200, W.C.A. Wijngaards wrote:

> broader scope.

As one of the co-chairs, I'd like to hear from working group
participants feedback on the following questions:

1.  Do you think that the DNSSECbis RFCs, including NSEC3, include
either implicitly or explicitly a notion of "degrees of trust" of
different keys?

    1. a. If so, please indicate the text that you think supports this
    view.

    1. b. If not, suggest why this departure from other security
    protocols is a plausible interpretation.  (If you're one of the
    editors of the docs, saying, "Because we thought it was a good
    idea, and if we wanted degrees of trust we'd have included it
    explicitly," counts.)

2.  Do you think that the DNSSECbis RFCs _should_ include that notion?
If so, why, and if not, why not?

Thanks,

Andrew (not speaking for Olafur).

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Chris Thompson <[email-masked]>
Date: 25 Jun 2009 21:04:08 +0100

>probably be less stale than local ones).

I am not sure that I understand exactly what these mean, in the
context of securely signed insecure delegations. Suppose HIGHEST
is configured and there is a trust anchor for the root, and that
(say) the delegation from the root to uk is signed, but that from
uk to ac.uk is not. Is a trust anchor for cam.ac.uk to be ignored
in this context, and cam.ac.uk to treated as unsigned regardless?

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 25 Jun 2009 16:17:47 -0400

[no hat]

> * ALL the trust-anchors must work (highly secure, for the truly

Does this mean, "All the trust anchors I have must work," or, "The set
of my trust anchors and the set of the name server trust anchors must
be equivalent"?  I guess it's obvious that the latter does not allow
adding keys without an outage.  Neither policy would allow an
emergency roll without an outage, I think.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: [email-masked]
Date: Thu, 25 Jun 2009 20:24:48 +0000

trust is binary
 trustworthy is not.

 the first test is ... is this blob trustworthy?  the criteria
 for determining trustworthiness can be many and varied... (local policy).
 once the trustworthiness has been established, then the simple binary 
 switch kicks in - yes/no.

 thats been my working model for, oh years and years.

--bill

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Thu, 25 Jun 2009 14:41:10 -0700

Bill and all,

  Yes mine also!  But you know of course that local policies very
greatly and as such problems of both trust and trustworthiness
ensue and than fester.

> > Andrew (not speaking for Olafur).

Regards,

Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln
"YES WE CAN!"  Barack ( Berry ) Obama

"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS.
div. of Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail
[email-masked]
My Phone: 214-244-4827

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 25 Jun 2009 18:13:00 -0400

Dear colleagues,

>     idea, and if we wanted degrees of trust we'd have included it

More than one person has pointed out to me now that there do not seem
to be any _protocols_ that have this notion of fractional trust.
There may be implementations.  I therefore cheerfully revise this
question.

    1.b.  IF not, suggest why you think it it does not include that
    notion even though many people seem to believe that fractional
    trust is a good thing.

Someone also argued to me (off list) that the issue we really have
here is not "fractional trust", but "layered trust".  This seems like
a possibly important distinction, but in the interests of brevity feel
free to read "trust layers" where "degrees of trust" is and see if it
changes your opinion.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 25 Jun 2009 16:07:48 -0700

>either implicitly or explicitly a notion of "degrees of trust" of

No.

>    notion even though many people seem to believe that fractional

It's fine that many people seem to think that: however, that does not mean we should promote it by including it in a base document. The documents should allow trust models that include fractional trust, layered trust, and something-that-we-invented-ourselves trust, but should only explicitly talk about the simplest and most common form of trust, full trust.

--Paul Hoffman, Director
--VPN Consortium

---

From: [email-masked]
Date: Fri, 26 Jun 2009 01:57:04 +0000

> There may be implementations.  I therefore cheerfully revise this

	then perhaps your are listening to the wrong sorts of people..

	Bradley R. Smith and J.J. Garcia-Luna-Aceves  have worked for
	years on "mulit-policy" models - although primarily for routing
	systems.  From Brads web page...

"The goal of my PhD work was to enhance the Internet's current distributed, hop-by-hop routing architecture to support a default multi-policy forwarding model as compared with the traditional default single-policy forwarding model. The concrete implication of this change in assumptions is that the dramatic jump in expected policy-route request rates makes the costs of on-demand, string-style policy-based routing unacceptable. "

	I hijacked some of his ideas earlier this decade in work on 
	the "DISCOVER" opcode, which was rejected by this WG.

	that said, you are likely correct that no current IETF maintained
	protocol supports anything other than "on-demand, string-style,
	policy".

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 26 Jun 2009 08:32:08 +0200

On Thu, Jun 25, 2009 at 09:04:08PM +0100,
 Chris Thompson <[email-masked]> wrote 
 a message of 29 lines which said:

> I am not sure that I understand exactly what these mean, 

Well, if I have time, I will rewrite it in proper I-D style.

> Suppose HIGHEST is configured and there is a trust anchor for the
> root, and that (say) the delegation from the root to uk is signed,
> but that from uk to ac.uk is not. Is a trust anchor for cam.ac.uk to
> be ignored in this context, and cam.ac.uk to treated as unsigned
> regardless?

Not at all. All four policies I listed are in the case where more than
one key (one trust anchor) can be used for validation (for starting a
chain of trust). In the case you mention, the root key cannot be used
(because it stops at ac.uk). So, in your example, only one key is
usable (cam.ac.uk) and this discussion does not apply.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 26 Jun 2009 08:36:39 +0200

On Thu, Jun 25, 2009 at 04:17:47PM -0400,
 Andrew Sullivan <[email-masked]> wrote 
 a message of 23 lines which said:

> Does this mean, "All the trust anchors I have must work," or, "The
> set of my trust anchors and the set of the name server trust anchors
> must be equivalent"?

I don't understand the second. What is "the set of the name server
trust anchors"? The DNSKEY found in the DNS and verified through DS?
If so, I would not call them trust anchors.

> Neither policy would allow an emergency roll without an outage, I
> think.

I did not suggest it to be the default policy. It just seemed to me
that some people may find it useful. My idea was to write something
like "These policies may [lowercase] be useful for some users so a
validating resolver MAY [RFC2119] allow them to be enabled via a
configuration option."

And we could add warnings such as yours.

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Fri, 26 Jun 2009 10:33:33 +0200

Hi Stephane, Chris,

> usable (cam.ac.uk) and this discussion does not apply.

I think this needs text in dnssec-bis-updates.  You try all keys, but 
they have to provide a chain of trust that passes the closest 
trustanchor (in a secure state).  This to prevent downgrade.

So, this does full trust for all anchors, but the rule makes sure that 
the anchor actually covers the domain of interest with security.  And 
the original closest trust-anchor, if not used because it is stale, 
becomes a statement that the trust anchor domain name must be signed.

Best regards,
    Wouter

---

From: "Antoin Verschuren" <[email-masked]>
Date: Fri, 26 Jun 2009 10:38:56 +0200

I have an extra argument in favor of the ANY should work policy, and that it's unwise to use the ALL or CLOSEST policy in default validators.
I would actually want to expand the ANY policy.

DNS is not static.
Chains of trusts change.
With the ALL or CLOSEST policy, you don't support these changes, and validation will fail during certain transactions that do happen in the real world.
These changes are completely legitimate.

As explained in a message to the IETF DNSOPS mailinglist on RFC4641bis, there is an operational difficulty to maintain trust when a delegation changes at a parent because of caching.
I want to expand the ANY policy by mandating that in case a chain of trust fails because a cached DNSKEY record cannot validate a newly received response for which the DNSKEY record should be validated against, that the validator MUST seek a new chain of trust by querying the parent to see if the delegation (NS and DS) and therefore chain of trust has changed before returning a failure.
If the delegation has changed, the cached DNSKEY record MUST be discarded and deleted from the cache.

I don't know if resolver or validation behavior like this can be mandated in dnssec-bis-updates or any other document, but if we can, we will certainly make life easier for dns-operators without introducing too insecure operational practices or abandoning the chain of trust model in DNSSEC.

It will also keep the core value of DNS in that it works, instead of "it only works when it is static and does not change".

Or have I missed something, and is this already mandated ?

Thinking more deeply, I think ANY should be a default policy, with the extra behavior as described.
HIGHEST can be a wise policy, also with the suggested extra behaviour, if systems are maintained well when root trust anchors change. (are they ?)

I don't see any real world deployment for ALL or CLOSEST other than paranoid monitoring purposes to inform that chains of trust have changed (legitimately) or on private networks for zones that are not officially delegated. So there are use cases for that, but not for a resolver on the real Internet that is supposed to work when resolving a name the same as without DNSSEC.

Antoin Verschuren

Technical Policy Advisor SIDN
Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  F: +31 26 3525505  M: +31 6 23368970
mailto:[email-masked]  xmpp:[email-masked]  http://www.sidn.nl/

> -----Original Message-----
> From: [email-masked] [mailto:owner-
> [email-masked]] On Behalf Of Stephane Bortzmeyer
> Sent: Thursday, June 25, 2009 2:30 PM
> To: Matt Larson
> Cc: Namedroppers Mailing List
> Subject: [dnsext] Re: Nested trust anchors (again)
>

---

From: Florian Weimer <[email-masked]>
Date: Fri, 26 Jun 2009 11:05:32 +0200

> Chains of trusts change.

Uhm, since the chain is tied to the name, how is this possible?

-- 
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: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 26 Jun 2009 11:26:40 +0200

On Fri, Jun 26, 2009 at 11:05:32AM +0200,
 Florian Weimer <[email-masked]> wrote 

> Uhm, since the chain is tied to the name, how is this possible?

I believe Antoin referred to scenarios like (for a validation of
www.weimer.example):

1) * The root is signed  and my resolver has a trust anchor for it
   * .example is not signed
   * weimer.example is signed and my resolver has a trust anchor for
     it

2) .example gets signed and the root publishes a DS

Then, a new chain of trust appeared, which was not there before.

Remember that the manager of the root announced a signature in 2009
and the manager of .com a signature in 2011-2012, so this scenario
will be very common.

---

From: "Antoin Verschuren" <[email-masked]>
Date: Fri, 26 Jun 2009 13:16:43 +0200

Stephane came up with another example of why DNS is not static, but I was also thinking:

The chain initially follows the delegation path when the trust anchor is above the name queried.
When the delegation path changes, the chain of trust priming changes too. (the trust anchor doesn't)

Current caching behavior makes it possible to cache an authoritative entry in the current chain of trust (DNSKEY) depending on the current delegation path.
When the delegation path changes, the chain of trust changes too, and this cached entry might not be in the path anymore.

So, root is signed, I have it's trust anchor in my resolver.

antoin.example. is delegated to ns1.example. with DS1, everything is signed.
I cache DNSKEY1, or may even set it up as a trust anchor.

At point x in time, the delegation for antoin.example. changes to ns2.example. with DS2 (new zone operator, new KSK, no rollover, new chain of trust)
DNSKEY1 is still in my cache, and I may have it as trust anchor, validation will fail until DNSKEY1 expires and/or I remove that trust anchor, and the resolver fetches DNSKEY2 in the new chain of trust.

Antoin Verschuren

> From: Stephane Bortzmeyer [mailto:[email-masked]]
> Sent: Friday, June 26, 2009 11:27 AM
> To: Florian Weimer
> Cc: Antoin Verschuren; Namedroppers Mailing List
> Subject: Re: Nested trust anchors (again)
>

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 26 Jun 2009 09:46:02 -0400

> If so, I would not call them trust anchors.

Yes, sorry for the imprecise language (which is painfully ironic given
I was trying to clarify, but there you go).  I just meant that there
are two ways to read that option.  One is that you have a bunch of
keys locally configured as trust anchors, and every one of them must
be available in the target zone.  The other is that all _and only_
those keys you have locally configured as TAs must be available as
keys in the target zone.  (They don't need to be verified through DS
from the parent at all, of course, and you might have the DNSKEY
record locally instead of the DS, depending on how your implementation
works.  But they have to correspond to your locally-configured keys.)

I think you mean "all must be there" and not "all and only those must
be there", but I wanted to be sure we have this right.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 26 Jun 2009 23:53:00 +1000

In message <[email-masked]>, "Antoin 
Verschuren" writes:
> Stephane came up with another example of why DNS is not static, but I =
> was also thinking:
> 
> The chain initially follows the delegation path when the trust anchor is =
> above the name queried.
> When the delegation path changes, the chain of trust priming changes =
> too. (the trust anchor doesn't)
> 
> Current caching behavior makes it possible to cache an authoritative =
> entry in the current chain of trust (DNSKEY) depending on the current =
> delegation path.
> When the delegation path changes, the chain of trust changes too, and =
> this cached entry might not be in the path anymore.
> 
> antoin.example. is delegated to ns1.example. with DS1, everything is =
> signed.
> At point x in time, the delegation for antoin.example. changes to =
> ns2.example. with DS2 (new zone operator, new KSK, no rollover, new =
> chain of trust)
> DNSKEY1 is still in my cache, and I may have it as trust anchor, =
> validation will fail until DNSKEY1 expires and/or I remove that trust =
> anchor, and the resolver fetches DNSKEY2 in the new chain of trust.

	So someone stuffed the key management on the authoritative
	side or it was an unauthorised change.  There is no way of
	knowing which from the validator's perspective.

	Do you risk accepting potentially bad data or do you stop
	accepting answers for the namespace?  Note there isn't a
	"correct" answer to this question.

	Mark

> mailto:[email-masked]  xmpp:[email-masked]  =
> http://www.sidn.nl/
> 
> 
> 
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20

---

From: Mark Andrews <[email-masked]>
Date: Sat, 27 Jun 2009 00:09:08 +1000

In message <[email-masked]>, Stephane Bortzmey
> and the manager of .com a signature in 2011-2012, so this scenario

	And there is still not a secure path from the root to
	weimer.example as there is no DS for weimer.example.

	Even when the DS RRset for weimer.example is added there
	is not a problem.  Presumably weimer.example published keys
	for use in trust anchors and should manage them accordingly
	or published then in a DLV only in which case they shouldn't
	be in a configation file or published them by both methods
	which requires that you meet the management constraints of
	both methods of publishing.

	If you just scrapped keys to add to you configuration then
	you get what you deserve when the zone operator fails to
	take you into account.

	Mark

---

From: "Antoin Verschuren" <[email-masked]>
Date: Fri, 26 Jun 2009 16:40:48 +0200

> From: [email-masked] [mailto:[email-masked]]
> Subject: Re: [dnsext] RE: Nested trust anchors (again)
> 
> 

The change is authorized.
By the parent.
You rely on your parent for the initial delegation and setting up the trust path anyway.
If you don't have a parent, or a parent is not involved in your trust path, I agree.
But I'm talking a parent in your trust path.
The trust anchor does not change.
The trust path has changed.
Only the validator doesn't know about it yet because of caching leaf data.

> 	"correct" answer to this question.

You can get the good data by re-walking the trust path from the trust anchor down.
That's what I'm saying.
Caches may store keys from the leaf which may not be in the path anymore.
That's what I call bad data, and should not stop the DNS from working.

Antoin Verschuren

---

From: Mark Andrews <[email-masked]>
Date: Sat, 27 Jun 2009 00:54:35 +1000

In message <[email-masked]>, "Antoin 
> The change is authorized.

	There have been cases where parents have been conned.

> You rely on your parent for the initial delegation and setting up the =
> trust path anyway.
> If you don't have a parent, or a parent is not involved in your trust =
> path, I agree.
> Only the validator doesn't know about it yet because of caching leaf =
> data.
> 
> You can get the good data by re-walking the trust path from the trust =
> anchor down.
> That's what I'm saying.
> Caches may store keys from the leaf which may not be in the path =
> anymore.

	Zones that are transferred from one set of servers to another
	today stop working due to cached data.  If care is taken
	this doesn't happen.  The same thing applies to with DNSSEC.

	DNSSEC is not a magic bullet.  It won't fix mis-management
	of delegations and changes to delegations.

	It is highlighting the current management problems in these
	areas and if it results in changes then that is a good
	thing.
 
	Mark

---

From: Paul Vixie <[email-masked]>
Date: Fri, 26 Jun 2009 15:13:03 +0000

dns distributes autonomy.  each zone depends on its ancestor zones for its
existence (NS RRs and possible in-zone glue) but not for its content.  to
decide between ANY or ALL or ANY+CLOSEST or CLOSEST, i recommend posing the
question "are my zone's trust anchors subject to my autonomy?"

if i've imported a key for ietf.org and it's working, and then .org gets
signed but doesn't yet have a key for ietf.org or worse still .org decides
that ietf.org should have to pay USD 1M/year for DS RR placement and so
publishes a deliberately bad key for ietf.org, then should my validator
stop accepting the key i imported?  it all depends on what we mean by zone
autonomy.  to me this is a strong argument against ALL.

or if ietf.org deletes a DNSKEY after a key compromise, but the .org people
are all down at the pub for a long weekend and somehow can't won't reflect
this change by deleting the DS RR associated with that DNSKEY, then there
is no way for any validator operator to manually set a trust anchor for
ietf.org and avoid spoofed data signed with the compromised key.  to me
this is a strong argument against ANY.

DLV's design faced similar decisions.  in the end we decided on strong zone
autonomy such that a DLV RRset at ietf.org.dlv.isc.org would still be
functional even after root and org are signed, or even after org.dlv.isc.org
has a DLV RRset.  this made a few TLD holders unhappy who felt that it was
uniquely up to the TLD whether dnssec worked or not for their subdomains.
i realize that "maximize autonomy" is not a universally held principle but
it's what guided the DLV design and i havn't grown at all unhappy about it.

i would prefer CLOSEST because i believe that the implementation should not
have to second guess its own configuration -- that is, if a validator has a
trust anchor configured then it should assume that the operator knows it is
there and wants it to be the final arbiter of security at/below the anchor.
however, i can live with ANY+CLOSEST because it's fairly simple and it allows
local autonomy in the revocation case without creating really long dependency
chains where absolutely everything (everywhere) has to be right all the time.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 26 Jun 2009 11:27:44 -0400

>     idea, and if we wanted degrees of trust we'd have included it

In RFC 2065 (aka DNSSEC I) and maybe RFC 2535 (aka DNSSEC II) we 
toyed with the notion of key strength as a field in a KEY RR.  We 
thought maybe you could mark a key to be stronger if it was the 
off-line signer of some data in a zone and use another key that was 
weaker as the signer of dynamic updates.  There were a few missing 
links, like, a relying party cannot distinguish between what is 
signed off-line and what was dynamically added.

The kicker was ... if there was a vulnerability exercised to add a 
KEY RR to the set the addition could as easily be a "strong" key as 
much as a "weaker" key.  If it was possible to add any key then 
making a distinction between strong and weak was useless.  Ergo, all 
keys are created equal (and none are "more" equal than others).

Key strength is not in RFC 403[345] (DNSSEC III).

>If so, why, and if not, why not?

No because it failed before.  In my opinion, no requirements have 
changed such that the reasons it failed back then have gone away.

>  for determining trustworthiness can be many and varied... (local policy).

Review RFC 2181, section 5.4.1.

On another note:

Somewhere I got the notion that there's a comparison to X.509 to be 
made.  In an architecture, an X.509 certificate and a DNSKEY RR play 
the same role - both associate ancillary data with a public key.  But 
the "competition" stops right there.  There are a lot more fields in 
X.509, these are used to relate the policy regarding the key, 
limitations on its use, the liability, etc.  X.509 is also backed by 
a Certification Processes Statement (CPS, I think that's the 
expansion), a form document that contains details ad nausem about the 
"meaning" of a successful validation resulting from the key in the 
certificate.  That's all "just too much" to lay upon a DNS 
administrator.  The functional requirements governing DNSSEC is a 
small subset of the functional requirements on X.509, resulting in 
the difference in implementations and, to answer the question that 
started this, why (DNS)KEY RR's don't have the same notions as trust 
as other systems like X.509.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 26 Jun 2009 11:34:39 -0400

>Uhm, since the chain is tied to the name, how is this possible?

Redelegation - in the sense that a zone cut may be removed but the 
names in the erstwhile child zone are "promoted" to the parent 
somewhere in the chain.

Key effectivitiy periods are not synchronous.

UDP is not reliable.

Etc.

The chain is not exactly tied to the name.  Remember that zones may 
be multi-label deep and there are empty non-terminals.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Mark Andrews <[email-masked]>
Date: Sat, 27 Jun 2009 08:56:44 +1000

The DNSSEC RFCs describes how you validate a trust relationship
from a given trust-anchor to a set of data and how you configure
zones for this to happen.

The do not however tell you how you choose which trust anchors you
are going to use for which names.  Trust anchors refer to keys but
are not keys themselves.  The rules for keys do not apply.

Try any key does not mean try any trust anchor.

Mark

---

From: Edward Lewis <[email-masked]>
Date: Sat, 27 Jun 2009 12:40:53 -0400

>Try any key does not mean try any trust anchor.

When I spent a lot of time analyzing the words in RFC 1034, section 
4.3.2, leading towards the wildcard update document RFC 
45something-or-other, a wise sage, Rob Austein, scolded me when I 
took the words "too literally," saying that the text in RFCs are not 
specifications, not a strawman of instructions, not a flowchart in 
text, not even pseudocode but simply an engineering description of 
the approach to solving the "problem."

DNSSEC has always maintained that local policy rules.  While the RFCs 
contain detailed information on the ways in which bits are 
manipulated to sign and validate data, the information on what a 
positive or negative outcome of a crypto-step is left to local 
interpretation.  The chief concern of the IETF, and that is conveyed 
via the RFCs, is interoperability and not overall "performance." 
I.e., what is specified is what is needed to make elements 
inter-relate and not all they need to do.

Back when I wrote an early validating application in 1998 I made some 
design choices.  I realized then one could write a ruggedized 
resolver that tried to get an answer in the face of a forged reply or 
one could write a lightweight resolver that would give up at the 
moment any irregularity was encountered.  Both approaches met the 
"requirements" of the RFC, both would interoperate, but one served 
it's user better, i.e., was of higher quality in my estimation.

When it comes to statements like "try any key does not mean try any 
trust anchor" I have to say I agree but at the same time, I wouldn't 
accept code that meets such a low bar of quality for my own use. 
E.g., I don't buy the cheapest legal tires for my car because I don't 
like to skid in a light rain - even though that is accepted legally.

Whether "try any key does not mean try any trust anchor" is not a 
point over which consensus matters to me, it's useless breadth to get 
to consensus as this is a matter of quality and not interoperability. 
The question is up to implementers, do they want to produce code that 
gets the job done or just merely meets the minimum acceptable needs 
and interoperates?  The question is, is an implementor trying hard to 
interpret the RFCs for to make code writing easy or trying to 
determine what is the best approach to solving a real world problem?

---

From: Michael StJohns <[email-masked]>
Date: Sat, 27 Jun 2009 13:43:59 -0400

At 06:56 PM 6/26/2009, Mark Andrews wrote:
>Trust anchors refer to keys but

Could you explain your reasoning for BOTH of the above statements please? (e.g. which rules don't apply and why?)

4033 is clear that the trust anchor is "A configured DNSKEY RR or a DS RR hash of a DNSKEY RR".  The first form is obviously a key.  The second form is a key reference that is just shorthand for the key given the way DNSSEC is defined.

 From WIKI - (Yeah, I know -but this is close to the definitions I've seen for PKI trust anchors and others including in the X509 standard) "In cryptography, a Trust Anchor is an authoritative entity represented via a public key and associated data." 

 From X509 "trust anchor: A trust anchor is a set of the following information in addition to the public key: algorithm identifier, public key parameters (if applicable), distinguished name of the holder of the associated private key (i.e., the subject CA) and optionally a validity period. The trust anchor may be provided in the form of a self-signed certificate. A trust anchor is trusted by a certificate using system and used for validating certificates in certification paths. "

All of these say - a trust anchor is a public key with associated data (trust point name, algorithms, conditions etc).

Why do you disagree?

Mike