Subject: [dnsext] Trust Anchors

From: Bob Halley <[email-masked]>
Date: Sun, 25 Oct 2009 06:05:21 -0700

I've been reading drafts in preparation for Hiroshima, and I noticed  
that in draft-ietf-dnsext-dnssec-bis-updates-09.txt, section 4.9 says

4.9.  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 validator
    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.

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

    There are some scenarios where different behaviors, such as choosing
    the trust anchor closest to the QNAME of the response, may be
    desired.  A DNSSEC validator MAY enable such behaviors as
    configurable overrides.

I reread the Trusted Anchors thread in the namedroppers archive, and I  
didn't see such a strong consensus for the ANY approach.  At best I  
saw support for ANY + CLOSEST (and perhaps other schemes).  Some  
people had a strong preference for only CLOSEST.  I didn't participate  
in that thread, but I too favor the CLOSEST approach.  Was there  
further discussion on this that I missed?  If not, I think the  
language in the draft is too strong, because it favors ANY and says  
that CLOSEST, while permissible, must be a "configurable override".

The purpose of the ANY approach appears to be system robustness.  The  
(certainly reasonable) concern is that statically configured trust  
anchors will go stale, and resolutions will fail.  While trying *more*  
statically configured data (i.e. other closer-to-the-root anchors) may  
help in some cases, this solution is not really getting at the real  
issue, which is static configuration.  We already have a standards  
track mechanism for keeping trust anchors fresh, namely RFC 5011.

I don't see any point to ANY.  It doesn't solve the staleness problem,  
it just adds hacks, which although they may be useful, may also be  
surprising and detrimental.  It also goes against the existing trust  
anchor practice of at least two validators (BIND and Nominum).

I propose that the draft mandate the use of CLOSEST and suggest the  
use of RFC 5011 to avoid staleness.  If there's no consensus for that,  
I'd be satisfied with just removing section 4.9.

/Bob

---

From: Paul Vixie <[email-masked]>
Date: Sun, 25 Oct 2009 16:30:12 +0000

if CLOSEST does not match but ANY does, then a system capture in an ancestor
can introduce trustworthy data about my zones without changing my zone's NS.

for example if the operators of COM were to sign (offline) some data about
SPELLING-ERROR.VIX.COM and sell these signatures to OpenDNS, it would be seen
as authentic.  never mind that the operators of COM, and the OpenDNS people,
are all good people and would not do this.  if it's BANK-OF-AMERICA.COM rather
than VIX.COM then we're giving some financial institutions a solid theoretical
basis on which to never (ever) allow DNSSEC to be used to authenticate their
online presence.

ANY would be a disasterous mistake.  CLOSEST is what we can go out and sell.
if somebody publishes one key and signs with another and complaint that their
parent key should have been allowed to work, we'll tell them, "all power
tools can kill, so please don't wrap the cord around your legs like that."

given the number of ways in which DNSSEC is hard to deploy, let's not add more.

so, i'm +1 on message-id <[email-masked]>
by bob halley.

---

From: Bob Halley <[email-masked]>
Date: Sun, 25 Oct 2009 11:27:06 -0700

> can introduce trustworthy data about my zones without changing my  

It doesn't have to change your NS RRs, but it does have to change your  
DS RRs.

> as authentic.

No.

RFC 4035 section 5 specifies that trust anchors are used to validate  
keys at the apex of the zone with the anchor's name.

As I understand the standard, COM could not hijack SPELLING-ERROR.VIX.COM 
  without altering VIX.COM's DS RRs.  If COM and VIX.COM were signed,  
a trust anchor at COM would say "start resolutions under COM in secure  
mode and make sure one of the keys for COM is this one".  That would  
establish a valid keyset for COM, and resolution would proceed in the  
usual way down to VIX.COM.  Assuming COM handed out the legitimate DS  
and NS RRs for VIX.COM, then anything in VIX.COM would have to be  
authenticated by one of the keys at the apex of VIX.COM.

So, to be clear, a compromised parent *can* hijack a child, but it  
must do so by altering the DS RRset for the child.  (Where "removing  
the DS RRset and converting the delegation to an insecure delegation"  
is included in "altering the DS RRset".)

Assuming that a validator had anchors for COM and VIX.COM, then here's  
a comparison of ANY and CLOSEST in various scenarios.
"Works" means "legitimate data validates and forged data does not  
validate".

Scenario							ANY			CLOSEST
-----------------------------------------------------------------------------------------------------------------------

Both anchors not stale				Works			Works

COM anchor not stale,
VIX.COM anchor goes stale,
but VIX.COM NS & DS
in COM still good						Works			Fails

VIX.COM anchor not stale,
COM anchor goes stale				Works			Works

Both anchors go stale					Fails			Fails

VIX.COM anchor not stale,
COM compromised,
VIX.COM DS RRs changed
in COM								Appropriately	Forged data
									forged data		never validates
									validates

									True data may	True data
									or may			always validates
									not validate

Supporters of ANY worry that during transition to DNSSEC you will set  
up your validator with a VIX.COM anchor, because COM is not signed  
yet.  Later COM will be signed, and you'll add an anchor for it and  
forget to remove the VIX.COM anchor.  If the VIX.COM anchor goes  
stale, under CLOSEST your resolutions will fail, whereas under ANY  
they will not.

Supporters of CLOSEST argue that the detection of a compromise or  
other problem in the parent is good security.

I'm sympathetic to the problems of staleness that ANY supporters worry  
about.  By my prior sysadmin experience tells me that if I configure VIX.COM 
  and COM both as trust anchors on my validator, and use ANY, than one  
of them will go stale and I'll not notice, and then when I'm on  
vacation the other one will go stale, and resolution will fail, and  
I'll get emergency phone calls.

I'd rather we kept CLOSEST for its security benefit in the compromise  
case, and tried to tackle anchor staleness directly (via RFC 5011 or  
some other means).

/Bob

---

From: Paul Vixie <[email-masked]>
Date: Mon, 26 Oct 2009 02:18:48 +0000

> From: Bob Halley <[email-masked]>
> Date: Sun, 25 Oct 2009 11:27:06 -0700
> 
> No.

thanks for explaining this.

> Supporters of ANY worry that during transition to DNSSEC you will set up
> your validator with a VIX.COM anchor, because COM is not signed yet.
> Later COM will be signed, and you'll add an anchor for it and forget to
> remove the VIX.COM anchor.  If the VIX.COM anchor goes stale, under
> CLOSEST your resolutions will fail, whereas under ANY they will not.
> 
> Supporters of CLOSEST argue that the detection of a compromise or other
> problem in the parent is good security.
> 
> about.  By my prior sysadmin experience tells me that if I configure
> VIX.COM and COM both as trust anchors on my validator, and use ANY, than
> one of them will go stale and I'll not notice, and then when I'm on
> vacation the other one will go stale, and resolution will fail, and I'll
> get emergency phone calls.
> 
> case, and tried to tackle anchor staleness directly (via RFC 5011 or some
> other means).

i get it.  i do not think the standard should address the multiple ancestor
problem since this is a configuration detail.  this could mean simply not
specifying the behaviour if there are multiple static trust anchors all
covering the signature that you're trying to validate.  but if we're going
to talk about multiple enclosing static trust anchors, i'd rather we say
that the closest one has to match and the others aren't looked at at all,
then to say any of them can match.  the RFC could also say that multiple
enclosing static trust anchors are a bad idea, and if they are configured
then the software should syslog a warning about it, early and often.

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Mon, 26 Oct 2009 14:41:39 +0100

Hi Bob,

+1 for CLOSEST.  (But I already voiced that before).

> then the software should syslog a warning about it, early and often.

There is even a worse problem than Paul mentions, use two layers
of trust anchor, ANY, and the following happens:

example.com: signed by local company, trust anchor.
com: signed but example.com is not signed, trust anchor.
(fairly regular case where the company uses a domain internally,
and .com is using, say, opt-out NSEC3)

In this case, the people from verisign and local IT are good,
and the anchors may be up to date, but some (spoofed) response
makes the validator to up from the valid example.com dnskey to
the securely-insecure-delegation from .com.

It can be fixed, 'MOSTLY-ANY', where the chain of trust MUST
extend securely to the lowest trust-anchor available.  Thus,
an invalid trust anchor is then not a no-op but instead it
states 'must be secure at this domain'.  If ANY is adopted
I suggest this so as to make it secure.

I think it is getting complicated for little benefit, hence CLOSEST.

Best regards,
   Wouter

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 26 Oct 2009 10:51:51 -0400

On Sun, Oct 25, 2009 at 06:05:21AM -0700, Bob Halley wrote:

> saw support for ANY + CLOSEST (and perhaps other schemes).  

Could you say more about what "ANY + CLOSEST" would be?  That is,
since closest is obviously inside the any chain, if any works then by
definition closest works, assuming closest is in fact a valid key.  

Is the idea of "ANY + CLOSEST" that any works as long as closest
works?  If so, how is that different from closest?

By the way, when we last discussed this I formed the impression of at
least a substantial number of people in favour of the ANY strategy, so
I'm surprised you came to a different conclusion on reading the
archive.  I'll go back and have another look, though.

> I'd be satisfied with just removing section 4.9.

Speaking with no hat, I am opposed to both of those options.

I oppose mandating the use of CLOSEST because, on my reading, it
imports degrees of trust into a system that is simply not designed
with degrees of trust in the first place.  I am especially
uncomfortable with promoting degrees of trust on the implict basis of
some other property.  

I oppose removing the section because it is quite plain that the issue
is not clear to everyone.  Those of us involved in an ICANN RSTEP
review of PIR's .org plans, for example, were all surprised by this
interpretation of the RFCs; and while I will happily concede that I am
often confused (so my own surprise might not be a big deal), I feel
rather strongly that the other participants' surprise was an
indication of a serious ambiguity in the specification.  I'd prefer to
see the inclusion of a mandate for CLOSEST than to see the section
dropped completely.

With my co-chair hat back on, but speaking only for myself, I think it
is super important that we come to some conclusion about this quickly,
produce the relevant text, and move on.  Let us please settle on
something and forge a consensus on it, so that we can tell the rest of
the world (which is busily deploying this technology) an unambiguous
story about how it all works.

Best,

A

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

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 26 Oct 2009 09:27:38 -0700

>uncomfortable with promoting degrees of trust on the implict basis of

+1. The IETF has seen this kind of feature creep in other security protocols, and the end result is always unexpected behavior for the relying parties. Even in protocols where degrees of trust were built-in from the beginning, namely PGP, the use of degrees were mostly abandoned by users or, worse, used without understanding. Even for pieces that have black-and-white trust but multiple trust anchors with intermediate certificates, it gets ugly really quickly. Just say "path validation with constraints" to a PKIX developer, and see if they cry (or laugh maniacally).

>see the inclusion of a mandate for CLOSEST than to see the section

+1, for the same reasons. Patrik can say how many times he had to explain this to me, even as we were reading the exact same words at the same time.

--Paul Hoffman, Director
--VPN Consortium

---

From: Bob Halley <[email-masked]>
Date: Mon, 26 Oct 2009 09:39:10 -0700

> definition closest works, assuming closest is in fact a valid key.

Sorry for being unclear.  What I meant by "ANY + CLOSEST" would be  
something like

Validators SHOULD allow a configurable choice between the CLOSEST and  
ANY trust anchor policies.  The default is left to the  
implementation.  Operators should consider carefully which policy is  
right for them.

To be clear, I still prefer a MUST or a SHOULD for CLOSEST.  But if  
there is not consensus for that, I'd settle for not blessing ANY as  
the default.

/Bob

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Tue, 27 Oct 2009 09:41:41 +0100

On 10/26/2009 05:27 PM, Paul Hoffman wrote:
> +1. The IETF has seen this kind of feature creep in other security protocols, and the end result is always unexpected behavior for the relying parties. Even in protocols where degrees of trust were built-in from the beginning, namely PGP, the use of degrees were mostly abandoned by users or, worse, used without understanding.

So its fine to put the anchors on an equal 'security' footing.
For the digital signature part.  The name in it does signify that
the operator wanted that name to be dnssec secure.

Now allowing that name to become secure using another key is fine with
me, but to stop possible downgrade attacks you really have to include
some language that says, for ANY, that if one anchor fails and another
is attempted, that the resulting chain of trust should securely reach
the original closest anchor.

So that, although you may use the root .com or example.com key
to validate www.example.com, the name 'example.com' was secure in
the chain of trust.

It is then a protection against some stale key for example.com
But that does not mean that example.com is allowed to become unsigned.

I realize this likely defeats some amount of the trouble we
try to save the operators here, because that stale key now prevents
rollover to unknown algorithms, the domain to change hands and then
become unsigned, ...

Many reasons to configure such anchors are exactly, say that example.com
is signed, but .com is not, and the root is.  The ANY mechanism allows
the security to be downgraded by spoofing for example.com, which is why
I attempt to get some extra language about covering the domain name of
the closest anchor with a secure part of the chain (I mean, not
unsigned).  And I am spending a lot of words on it, because people say
this is confusing.

It is not degrees of trust I want, but rather to avoid downgrades:
CLOSEST is simple, simple to understand, and very secure.

Configuration that makes certain trust anchors applicable only to
a particular part of the DNS tree - in high detail for security
minded people - should not be ruled out, I think.  Does scoping
keys create such (evil) feature creep with degrees of trust in it?

Best regards,
   Wouter

---

From: João Damas <[email-masked]>
Date: Tue, 27 Oct 2009 14:10:56 +0100

the operational problem here is, again, that resolver operators don't  
necessarily sync-up with zone producers.

I also think that closest should be the way to go when you have 2 or  
more keys that can validate a given signature.

Given this is an operational problem, I believe tweaking the protocol  
will never yield a perfect solution and that this sort of situation  
would see the users better served by crafting a BCP where, for  
instance, the choreography necessary for domain moves between  
registrars would be listed.
The situation when a parent zone becomes DNSSEC enabled (allowing DS  
records to be stored there and signed) might lead to an operational  
recommendation for the child zone producer to keep the keys unchanged  
from the time when the zone was an island, that is: do not roll just  
because your parent became DNSSEC-enabled.

Joao

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 27 Oct 2009 10:20:31 -0400

No hat.

> But that does not mean that example.com is allowed to become unsigned.

[…]

> unsigned).  And I am spending a lot of words on it, because people say

For me, at least, all that the changes to dnssec-bis-updates should
say is that, if there are two paths for a validation of a given name,
using different trust anchors at different distances in the tree,
either one is as good as any other.  You are, however, pointing out a
nasty consequence of the current proposal: when the closest TA does
not validate, and a distant TA does validate but there is an
intermediate zone that is unsigned, you move the target domain from
"bogus" to "insecure".  I think this is a good point (but I didn't
understand what you were saying until this message.  Sorry I'm so
thick).

Now, what bothers me about saying, for simplicity's sake, "Do
CLOSEST," (because the real issue is too hard to explain or
understand) is that we are almost guaranteeing false failures by
picking "CLOSEST".  The usual response to this concern is, "Yes,
people have to be super-competent in operating their zones during
DNSSEC adoption."  To me, that position flies in the face of all our
experience with the actual operation of the DNS.  We know that there
are plenty of zones out there that are operated quite badly without
DNSSEC.  We're asking either that, overnight, all those human errors
go away, or else that people accept that they have to trade
unreliability to get the security we are trying to sell them.

I believe that what will happen, if we stick with CLOSEST, is that a
number of domains will have nasty experiences with DNSSEC.  The report
that ends up going to management when each outage happens will be,
"Due to DNSSEC, our domain became unavailable to CustomerC from
$starttime to $endtime."  Management in each case will say, "How much
do we need this DNSSEC anyway?"  Since the advantage of DNSSEC to the
publisher of the DNS data is not that great, the incentive will not be
strong to continue using it, and pretty soon this useful technology
will get a reputation as another complicated, doesn't-work thing that
should just be turned off.

Finally, the argument that there is an important downgrade available
under ANY depends on the premise that, in validating cases, there is a
valuable difference between "bogus" and "insecure".  Mike StJohns has
argued strongly that, for practical purposes, if you are really going
to check validation you're not going to care what the reasons are that
something doesn't validate.  If that's right, then there is no
_practical_ downgrade path here anyway.  I don't know whether he's
right, however.

I therefore think that we ought to work on text that makes it clear
that the postive-validation paths are all just as good as one another,
but that a good security policy might prefer bogus over insecure paths
in case postive validation is not at all possible.

Best,

A

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

---

From: Thierry Moreau <[email-masked]>
Date: Tue, 27 Oct 2009 11:51:11 -0400

See inline below.

In a related discussion on another forum, I indicated that I would stop 
discussing. But I couldn't resist making the connection below. These 
things belong to the DNS experts on this list, don't they?

Regards,

- Thierry Moreau

> in case postive validation is not at all possible.

The DNS root signature deployment plan includes a gradual roll-out phase 
during which the policy should be (must be?) to prefer insecure over 
bogus in a case where the protocol allows either.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 27 Oct 2009 11:56:01 -0400

> bogus in a case where the protocol allows either.

Surely that's not exactly relevant to the case under discussion,
because there can't possibly be a downgrade for the root due to some
higher-level intermediate insecured zone.  Right?

A

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

---

From: Thierry Moreau <[email-masked]>
Date: Tue, 27 Oct 2009 12:07:37 -0400

> higher-level intermediate insecured zone.  Right?
If you establish a policy for one concern, should you care about other 
impact of the policy?

- Thierry

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 27 Oct 2009 14:19:33 -0400

As before, no hat.

> If you establish a policy for one concern, should you care about other  

Only if it has such an effect.  I am arguing that there could be no
such effect here, if the policy is designed correctly, because the
point of the policy is to avoid downgrades where there is an insecure
link in the chain.  As there is no such possible downgrade in this
case, we don't have to worry about it.

If what you're saying is, "The language ought to be tailored to avoid
this sort of problem," I agree.  But if you're saying that this has
implications for the root, I strongly disagree.

A

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

---

From: Joe Abley <[email-masked]>
Date: Wed, 28 Oct 2009 11:14:45 +0000

On 2009-10-27, at 13:10, João Damas wrote:

> Given this is an operational problem, I believe tweaking the  
> protocol will never yield a perfect solution and that this sort of  
> situation would see the users better served by crafting a BCP where,  
> for instance, the choreography necessary for domain moves between  

This is very much an aside, but I continue to be mildly alarmed by the  
conflation of "registrar" with "zone manager" in this kind of  
discussion.

Changing registrar in and of itself has no impact on DNSSEC, and there  
is no requirement to roll keys or change trust anchors as part of a  
registrar transfer. This is a simple database operation at the  
registry, and does not effect what is published in the DNS at all.

The case where you need to manage a key rollover is when the entity  
managing the zone  changes.

I appreciate that there cases where a single organisation carries out  
both functions (registrar and zone manager) but this is certainly not  
the general case.

For example, I have heard concern that without the problem of  
transfers between registrars being solved, prominent/popular domains  
will never be signed. Any such concern is very easily avoided by not  
having a registrar sign the zone in the first place.

Perhaps the useful BCP to promote in this area is "don't let other  
people hold your keys if you care about your zone". Surely this is  
obvious, though.

Joe

---

From: Jim Reid <[email-masked]>
Date: Wed, 28 Oct 2009 11:52:10 +0000

On 28 Oct 2009, at 11:14, Joe Abley wrote:

> Changing registrar in and of itself has no impact on DNSSEC

I'm not sure that will always be the case Joe. Of course it should  
be....

Delegation metadata shouldn't change at the registry when the  
registrar changes. But it would not be wise to assume that. For  
instance, what if the registrar is involved in submitting the  
registrant's (zone manager's) KSK to the registry, say in an EPP  
transaction? Bad Things could happen at the registry if the EPP  
transfer request fails to include the delegation's KSK(s). For  
instance would this hypothetical transfer without KSK(s) transaction  
mean it's still OK for the current KSK(s) to be used or not?

> I have heard concern that without the problem of transfers between  
> registrars being solved, prominent/popular domains will never be  
> signed. Any such concern is very easily avoided by not having a  
> registrar sign the zone in the first place.

True. But this is somewhat idealistic IMO if DNSSEC ever becomes  
mainstream. The vast majority of people with domain names rely on  
their ISP or registrar as their source of DNS clue. So it's inevitable  
they'll turn to that source when it comes to signing their zones, just  
as they turn to them for DNS/mail/web hosting. I'm doubtful that  
uptake of DNSSEC is going to be encouraged by pushing the complexity  
of signing and key rollover out to the edges of the network where the  
DNS skill levels are low.

BTW this thread probably should move from namedroppers if it continues.

---

From: João Damas <[email-masked]>
Date: Wed, 28 Oct 2009 13:06:17 +0100

On 28 Oct 2009, at 12:14, Joe Abley wrote:

>> situation would see the users better served by crafting a BCP  
>> where, for instance, the choreography necessary for domain moves  
>> between registrars would be listed.
>
> This is very much an aside, but I continue to be mildly alarmed by  
> the conflation of "registrar" with "zone manager" in this kind of  
> discussion.
>

depends were the key-related info resides, and even on who holds the  
key. Although providing the DNS service is indeed not the same as  
being a registrar, I find it likely that the registrar, which  
currently keeps the list of NS, if any, will also keep the key-related  
info (e.g. DS to be sent to the parent). It is also possible there  
might be a third party dealing with the DNSSEC info, though it is hard  
to imagine how to fit that new entity into the customer-registrar- 
registry trio.

Joao

---

From: Joe Abley <[email-masked]>
Date: Wed, 28 Oct 2009 12:42:14 +0000

I take Jim's point about the proper forum for this particular  
extemporaneous rant, but ignoring it for a second...

On 2009-10-28, at 12:06, João Damas wrote:

> key.

My point is that the key isn't part of the registry data,

> Although providing the DNS service is indeed not the same as being a  
> registrar, I find it likely that the registrar, which currently  
> keeps the list of NS, if any, will also keep the key-related info  
> (e.g. DS to be sent to the parent).

the trust anchor to the registrant's zone is public information, is  
held at the registry, and doesn't need to change during a domain  
transfer, and

> It is also possible there might be a third party dealing with the  
> DNSSEC info, though it is hard to imagine how to fit that new entity  
> into the customer-registrar-registry trio.

although single organisations frequently perform multiple roles, the  
zone manager role already exists and is already independent of the  
registrant-registrar-registry roles.

Joe