Subject: Confusion about trust anchors and DS records from the parent?

From: Andrew Sullivan <[email-masked]>
Date: Thu, 5 Jun 2008 11:58:20 -0400

(No hat)

Dear colleagues,

I was recently arguing (off list) that if the parent of an island of
security gets signed, the (former) island of security does not have to
worry about the trust anchors validators might have for it, assuming
that the zone operator can be reasonably sure that validators had
loaded the new trust anchor for the parent.  That is, if I'm
teenysite.hugezone.com and I know that people have my TA configured,
if hugezone.com gets signed I can stop worrying about TA rollovers,
because I just publish my DS in hugezone.com.  Since anyone who has my
TA configured is extremely likely to configure the TA of hugezone.com,
if they fail to remove my TA, I don't have to worry about those old
TAs when rolling keys.  (Substitute zones appropriately higher in the
tree, and this argument becomes somewhat more plausible.)

My reasoning was that RFC 4035 says (in section 5.1) that normal
processes for validating should apply to islands, and says in 5.3.3
that it's possible for more than one signature to match the required
procedure, so you have to try all of them.

Someone argued (and demonstrated) in response that both BIND and
Unbound don't actually work the way I expected.  They'll both prefer
the TA deeper in the tree instead, and when that fails, they won't use
the DS from the parent.

Since it seems that at least two implementations have behaviour that
differs from what I expected from reading RFC 4035 (and since others
read the same RFC and agreed with my interpretation), I believe some
clarification is needed.  I have two questions.

1.  What do others think the right behaviour is in this case?

2.  Is something needed in dnssec-bis-updates to make the correct
behaviour plain?

Best regards,

Andrew

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

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Mark Andrews <[email-masked]>
Date: Fri, 06 Jun 2008 10:19:30 +1000

> tree, and this argument becomes somewhat more plausible.)

	You should always roll keys in a way that allows automata
	to follow the rollover.  At a miminum you need to make it
	clear to the existing TA users that you are not supporting
	automated TA rollovers anymore.
 
> procedure, so you have to try all of them.

	Signatures != trust anchors.
 
> 2.  Is something needed in dnssec-bis-updates to make the correct

	If you have a trust anchor then it needs to be managed.

	If I have a private version of a zone that it signed and a
	public version of the same zone zone that is signed. Then
	by configuring the private trust anchor the validator will
	reject anything that leaks from the public zone.

	Similarly if I have a trust anchor for my company I really
	don't want to trust the DS from the infrastructure zone to
	ensure that the answers for my zone are validated from the
	trust anchor for my zone.

	Things are fuzzier when you talking root and TLD but in
	general if you configure a deeper trust anchor then by
	the act of adding that trust anchor you are saying that
	you place more trust in it than in the chain from the
	higher trust anchor.  I know this may not neccessarially
	be true as we are currently doing bottom up development
	but in the long term that is the clear statement you are
	making.

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

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 5 Jun 2008 22:21:09 -0400

> 	reject anything that leaks from the public zone.

I understand this use case, but it's also what's troubling me about
the behaviour.  There's nothing anywhere in the protocol, as near as I
can tell, to indicate anything like "degrees of trust".  The reported
behaviour appears to be sneaking that functionality in through the
back door.  I'm asking whether we want that functionality; and, if we
do, whether the documents as they stand are clear enough on this or
whether we need clarifying text.

A

---

From: Mark Andrews <[email-masked]>
Date: Fri, 06 Jun 2008 13:00:09 +1000

> whether we need clarifying text.

	There is no sneaking anything here.  These use case have
	been discussed for years.  I don't think anyone thought one
	would ever want to go back past a trust anchor which failed
	to validate the matching DNSKEY RRset and to then look for a
	higher trust anchor.  In my thinking it is a dangerous policy.

	Mark

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 5 Jun 2008 20:50:58 -0700

>	automated TA rollovers anymore.

Over which communication channel is that done?

--Paul Hoffman, Director
--VPN Consortium

---

From: Niall O'Reilly <[email-masked]>
Date: Fri, 06 Jun 2008 09:59:23 +0100

On 6 Jun 2008, at 04:00, Mark Andrews wrote:

> [MA] There is no sneaking anything here.

	That's arguable, especially as Mark seems to be using the term
	"sneaking" in a different sense from Andrew's.

> [MA] These use case have been discussed for years.

	That's at least verifiable.

> [MA] I don't think anyone thought one

	Andrew's question was

> [AS] whether we want that functionality; and, if we

	Mark, you seem to be saying that whatever discussion has
	taken place over the years is all the documentation we need.
	Is that how you intended to be understood?

	Best regards,

	Niall O'Reilly
	University College Dublin IT Services

	PGP key ID: AE995ED9 (see www.pgp.net)
	Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 6 Jun 2008 11:25:25 +0200

> 	higher trust anchor.  In my thinking it is a dangerous policy.

If that was the conclusion, and still is the conclusion, then I say  
that a clarification in the RFCs is definitely needed.

    Patrik

---

From: Wouter Wijngaards <[email-masked]>
Date: Fri, 06 Jun 2008 11:47:53 +0200

Patrik Fältström wrote:
| On 6 jun 2008, at 05.00, Mark Andrews wrote:
|
|>     There is no sneaking anything here.  These use case have
|>     been discussed for years.  I don't think anyone thought one
|>     would ever want to go back past a trust anchor which failed
|>     to validate the matching DNSKEY RRset and to then look for a
|>     higher trust anchor.  In my thinking it is a dangerous policy.
|
| If that was the conclusion, and still is the conclusion, then I say that
| a clarification in the RFCs is definitely needed.
|
|    Patrik

During the development of unbound, this question came up.  No text in
RFCs could be found.  In unbound we wanted the most secure default
settings.  So, similar to Mark Andrews, going up is dangerous, there is
no text, thus we didn't do it.

Unbound has one exception, if parentzone gives a name error during
resolution, and it is signed, the parentkey is used to validate that
answer.  Otherwise, childkey is used for the childzone.

Best regards,
~   Wouter

---

From: Shane Kerr <[email-masked]>
Date: Fri, 6 Jun 2008 11:52:48 +0200

Andrew,

> 1.  What do others think the right behaviour is in this case?

It is hard for me to imagine a case where you trust the parent to hand  
out NS records but not DS records. :)

I think that your reasoning is correct, and that resolvers should use  
a logical OR of the TA.

> 2.  Is something needed in dnssec-bis-updates to make the correct

Since it appears all implementations use only the most-specific TA, I  
think so. :)

--
Shane

---

From: Alfred Hönes <[email-masked]>
Date: Fri, 6 Jun 2008 13:34:38 +0200 (MESZ)

Shane,
thanks for your notes.

>> the TA deeper in the tree instead, and when that fails, they won't
>> use the DS from the parent.
>>
> It is hard for me to imagine a case where you trust the parent to
> hand out NS records but not DS records. :)
> 

Exactly. 'Trust' per definition is a cumulative matter.

Trusting <B> never can mean a reduction in also established
trust in <A>.  There's no protocol element in DNSSEC to define
or distribute *distrust*.
TAs establish trust to a DNS (sub)tree extending as far as valid
signature chains can be followed, without additional exceptions.

Hence, the only possible, conceptually and logically consistent
solution is to operate with the *union* of all trust configured,
or, as you said, the logical OR of TAs.

Beware that similarly, if a zone has multiple signature keys,
verification of a single signature suffices to accept an RRset
as valid.  Here again the principle can be observed that a single
valid signature chain conveys trust that cannot be revoked by a
failure to validate another possible chain.

> Since it appears all implementations use only the most-specific TA,
> I think so. :)

+1

  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Frederico A C Neves <[email-masked]>
Date: Fri, 6 Jun 2008 09:36:34 -0300

> out NS records but not DS records. :)

Completely agree. Specially when there is a greater trust value on
them, DSs are not just hints like the NSs.

> Since it appears all implementations use only the most-specific TA, I  

There is one tha behaves differently. dig sigchase fails the
most-specific and then follows the less-specific TA and validates.

Fred

---

From: "Roy Arends" <[email-masked]>
Date: Sat, 7 Jun 2008 01:23:10 +0200

> 1.  What do others think the right behaviour is in this case?

It is my opinion that the desired behavior is as follows:

When there are multiple chains of trust, at least one must validate 
correctly. 

We have explicitly avoided terms like 'more trusted' or 'more secure' when 
writing these documents. I feel uncomfortable to blindly assume that the 
shortest chain of trust is the most secure. To measure the most secure, 
we'd have to include algorithm type, key size, even key age, and that is a 
slippery slope, and we need to avoid that. 

> 2.  Is something needed in dnssec-bis-updates to make the correct

Yes. We need to add text to dnssec-bis-updates to make that explicit.

Note that the there is text in RFC 2535 that supports the current behavior 
of BIND and UNBOUND. However, that does not appear in the subsequent 
DNSSEC standards which obsoletes 2535.

   6.3.2 Conflicting Data

   It is possible that there will be multiple SIG-KEY chains that appear
   to authenticate conflicting RRset answers to the same query.  A
   resolver should choose only the most reliable answer to return and
   discard other data.  This choice of most reliable is a matter of
   local policy which could take into account differing trust in
   algorithms, key sizes, staticly configured keys, zones traversed,
   etc.  The technique given below is recommended for taking into
   account SIG-KEY chain length.

   A resolver should keep track of the number of successive secure zones
   traversed from a staticly configured key starting point to any secure
   zone it can reach.  In general, the lower such a distance number is,
   the greater the confidence in the data.  Staticly configured data
   should be given a distance number of zero.  If a query encounters
   different Authenticated data for the same query with different
   distance values, that with a larger value should be ignored unless
   some other local policy covers the case.

I would rather avoid a protocol fight over this. I think it is sensible to 
assume that all configured trust anchors are all trusted equally, which 
implies that all chains of trust should be trusted equally, so it would 
suffice to have one validated chain of trust. In case one chain fails, try 
the next chain. 

Thanks,

Roy

---

From: Paul Vixie <[email-masked]>
Date: Sat, 07 Jun 2008 02:29:47 +0000

> ...

agreed.

> ...

i would like to retain the option, non-default, of requiring that a zone use
a key that i have an anchor for.  but just as any RRSIG->DNSKEY->DS chain
that works causes success, even if some don't work, so it should be, by
default, that if a trust anchor isn't needed, it won't be used, and so it
won't matter whether or not it would work if tried.

---

From: Olaf Kolkman <[email-masked]>
Date: Mon, 9 Jun 2008 06:34:48 +0200

>> Yes. We need to add text to dnssec-bis-updates to make that explicit.

1++, bis needs clarification.

> won't matter whether or not it would work if tried.

During DNSSEC bis development we have used the stop-gap local policy  
in many cases and I believe this was one.

I would argue that one would like to retain an option for (any) local  
policy. The update document should be very clear about what the  
default is and allow for other use-cases. I can subscribe to both the  
use case where closest trust-anchor is authoritative for the  
validation and the use case where the chain of trust overwrites the  
closest trust-anchor. For the latter I can see many different policies.

Anyhow I can consent with keeping the closest trust-anchor as authority.

I can see the need for a small client side maintenance tool: One that  
implements the timers-rollover and also one that clears out trust- 
anchors for which longer chains exist (Labs is working on it :-) )

--Olaf

--Olaf

---

From: "Roy Arends" <[email-masked]>
Date: Mon, 9 Jun 2008 07:03:39 +0200

> Anyhow I can consent with keeping the closest trust-anchor as authority.

As an option, or as the default?

Roy Arends
Nominet UK

---

From: David Blacka <[email-masked]>
Date: Mon, 9 Jun 2008 09:20:47 -0400

On Jun 9, 2008, at 12:34 AM, Olaf Kolkman wrote:
> I would argue that one would like to retain an option for (any)  
> local policy. The update document should be very clear about what  
> the default is and allow for other use-cases. I can subscribe to  
> both the use case where closest trust-anchor is authoritative for  
> the validation and the use case where the chain of trust overwrites  
> the closest trust-anchor. For the latter I can see many different  
> policies.

To be clear, I don't think anyone suggested having the chain of trust  
"overwrite" the closest trust anchor.  Instead, the suggestion was  
simply to try all trust anchors until one succeeded.

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

---

From: Edward Lewis <[email-masked]>
Date: Mon, 9 Jun 2008 10:49:43 -0400

>As an option, or as the default?

I would opine that the on-line learned key is superior to the 
statically configured trust anchor.  Yeah, I know it's safer to trust 
the disk than ether, but the ether is probably more fresh.  And 
"superior" doesn't necessarily mean more trustworthy.

If the TV news says the bridge was washed out by the storm but your 
hand drawn map made last week shows there is a open bridge, what do 
you rely on?  Even if the news report was sandwiched between a report 
of an alien abduction and the presentation of the lottery numbers?  I 
bet you'd trust that the bridge was unusable.

Ultimately, to avoid security just making the system more brittle and 
rigid, if there is a verifiable copy of the data, go for it.  But 
maybe more cautiously if there are conflicting reports.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.

---

From: Peter Koch <[email-masked]>
Date: Mon, 9 Jun 2008 18:39:07 +0200

agreed.

> closest trust-anchor. For the latter I can see many different policies.

Thinking of the introduction of DNSSEC for e164.arpa, where the zone
was signed without publishing DS RRs for a couple of months, we might
need both ways, so a logical "or" seems reasonable to me.

-Peter

---

From: Michael StJohns <[email-masked]>
Date: Mon, 09 Jun 2008 12:51:18 -0400

>        higher trust anchor.  In my thinking it is a dangerous policy.

I delayed a response hoping you'd explain why you think this is a "dangerous policy".  

Your approach is a violation of the "be generous in what you accept" principle.   Granted that for "security" reasons, we sometimes violate this, but I doubt there are any reasonable security reasons for not allowing a DNSKEY RRSet to be validated by chaining even if you've got a trust anchor for the sub zone that doesn't validate the RRSet.

Look, the in-band signalling of whether a trust anchor for a zone is still valid (RFC5011 for example) is, due to the nature of DNS, a very loosely coupled protocol.  It's possible  the termination of publication of separate trust anchors for the zone following the security adoption (e.g. publishing of DS records) of a signed subzone by its parent could be missed by a resolver, either due to timing issues or due to the zone owner fumbling the process.    The resolver may have a chainable signature through a DS record pointing to a SEP DNSKey that signs the apex DNSKey RRSet while still having a DNSKey trust anchor that no longer is part of that RRSet.  Under your rules, that zone, although validly signed, would be considered bogus.

>won't matter whether or not it would work if tried.

I can't parse this.  The first part says "I want to use the trust anchor", but I think the second part says "If I'm able to validate by not using a trust anchor (?? by chaining ??) then I won't use the trust anchor"?  Or did you mean - "If I have trust anchors configured for a zone, then I want the option to try validation with them and only them and if any trust anchor validates, then the zone validates otherwise it does not validate regardless of whether it validly chains"?

As Olaf notes in one of his emails, local policy may certainly be specified.  I'd recommend against permitting your suggestion (trust anchor only validation) as a local policy because it increases the fragility of the system without providing any security (my opinion) - but wouldn't argue too strenuously as long as the default is that any validation path validates the zone.  I'd hope that you (or Mark) would provide additional text as to why a resolver owner might turn on the trust-anchor-only-validate option as a condition for adding the option to the text of the revision.

Mike

---

From: [email-masked]
Date: Tue, 10 Jun 2008 13:03:03 +0000

> simply to try all trust anchors until one succeeded.

	actually, this may be the wrong alogrithm.
	trust comes in degrees.  one thing we tried was
	where the closer to the root, the less trust in the
	anchor - based on the presumption that one trusts ones
	peers (the folks "closest" to me in the naming heirarchy)
	more than folks farther away from me in the naming heirarchy.

	similar arguments can and have been made regarding key
	lengths; e.g. the closer to the root, the longer the key
	length.

--bill

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Jun 2008 10:55:44 -0700

At 1:03 PM +0000 6/10/08, [email-masked] wrote:
>	trust comes in degrees.

In people, yes definitely. In protocols, rarely. Where in DNSSEC are 
"degrees of trust" described?

>	one thing we tried was

Given that we're talking about trust anchors installed in DNSSEC 
resolvers, what makes a particular resolver "closer to the root" for 
this algorithm?

--Paul Hoffman, Director
--VPN Consortium

---

From: [email-masked]
Date: Tue, 10 Jun 2008 22:48:33 +0000

> "degrees of trust" described?

	DNSSEC treats all trust as atomic.  This is (imho) a weakness,
	-IF- one presumes all atomic transactions are equally valid.

> resolvers, what makes a particular resolver "closer to the root" for 

	trust anchors that are for points nearer to me in the name
	heirarchy are closer to me than points farther away.  e.g.
	if I am the node  bill.gov.br.  - i would likley have a 
	local policy to have a higher confidence in the "gov.br" trust
	anchor than in either the "br" or "." trust anchor.

-bill

---

From: Edward Lewis <[email-masked]>
Date: Tue, 10 Jun 2008 19:25:12 -0400

>	-IF- one presumes all atomic transactions are equally valid.

But the entire question being answered by DNSSEC is "did this record 
come from the appropriate zone admin?   Yes or no?"

It's not like, "well www.bill.mars. has an v4address of 287.214.11.78, +/- 6."

DNSSEC will tell you if the record came from the signer.  It can't 
and won't tell you if the record is the freshest, most accurate, or 
best.  That's because those capabilities didn't exist in DNS when we 
started.

We can't do freshest because DNS lacks time.
We can't do accurate because admins have historically fat fingers.
We can't to best because, well, that depends on what the measure is.

We only hardened the pipes.  We didn't bend them.

Although we tried.

---

From: [email-masked]
Date: Wed, 11 Jun 2008 01:39:28 +0000

> We only hardened the pipes.  We didn't bend them.

	so, young Ed.

	what happens when this validator gets back -two- answers with
	different data?  I know, always use the first one back - cause 
	all we got is QUERY.  So we do "freshest" where that is the first
	thing back.  

	(me, on the other hand, I have DISCOVER,
	so I can get multiple replies and have to figure out what happens
	when near duplicates occur...)

	trying to do "best" - where best is defined as local policy.

--bill (still bending pipes in the basement...)

---

From: Edward Lewis <[email-masked]>
Date: Tue, 10 Jun 2008 23:10:17 -0400

>--bill (still bending pipes in the basement...)

So, wizened sage Bill,

For years "resolvers" (in the days before validators) would just get 
the first arrival, fold up the socket and pass on the result.  Once 
we added the SIG record (and then whatever they are now) with 
expirations and inception times we thought we had introduced absolute 
time to the DNS and the ability to handle multiple answers.  Oh what 
fools we were!

I remember a phone call one day, I was at that house on the Severn. 
Great place, scenic, quiet and restful.  As I paced the deck I was on 
a call listening to our illustrious WG chair tell me about a goofy 
idea to use the expiration and inception times for "a good purpose."

The problem was and still is is that the inception and expiration 
times are not time stamps!  What if I sign an A record set with key A 
for 1-7/6/2008 (as in June 1st-7th), and key B for 8-14/6/2008.  Then 
I find that, in three days, the set is wrong and I sign it with key C 
for 4-10/6/2008.  Which is "fresher"?  The signature for 8-14/6 or 
4-10/6?  The former was signed first but has a later effectivity.

You want duplicates?  An exchange between Lt. Kaffee and Col. Jessep 
comes to mind:

Kaffee:      "I want the duplicate!"
Jessep:      "You can't handle the duplicate!"

---

From: Mark Andrews <[email-masked]>
Date: Wed, 11 Jun 2008 20:24:07 +1000

> come from the appropriate zone admin?   Yes or no?"

	I'm the zone admin.  I know what my trust anchor is.  I've
	configured it into named.conf.  I don't want named trusting
	anything that doesn't verify against the trust anchor that
	I have in my config.  The fact that I also have a trust anchor
	for higher up the tree does not change say that I want to accept
	answers that don't validate against my trust anchor.  The trust
	anchor for higher up in the tree is for my neibours, not for
	my own zone.

---

From: Shane Kerr <[email-masked]>
Date: Wed, 11 Jun 2008 13:38:56 +0200

Mark,

> 	anchor for higher up in the tree is for my neibours, not for

If you're the zone administrator, why didn't you send your DS record  
to your parent zone?

Or did your parent somehow publish a DS record without your permission?

In either case, why do you trust your parent to publish NS records  
(not authoritative I know, but resolvers have no way to find your  
servers without them), but not DS records?

To be honest, I think it is perfectly acceptable for software to  
implement this if for some reason an administrator actually wants this  
behavior.

But the general case will be for someone (not the zone administrator)  
to forget they configured a trust anchor locally and suffer some  
period of breakage until they figure out why DNS stops working when  
going to a specific domain, after the administrators of that zone  
publish DS records in their parent and they stop maintaining a  
separate trust anchor. DNSSEC should tend towards not breaking, if at  
all possible, especially considering the state of the debugging tools  
right now. :-/

So, is there any objection to making the default a logical-OR of all  
trust chains, but allowing local configuration to override that? (I  
think this is what Olaf was suggesting.)

--
Shane

---

From: [email-masked]
Date: Wed, 11 Jun 2008 12:04:03 +0000

> time to the DNS and the ability to handle multiple answers.  Oh what 

	regardless, since the resolver itself still is stuck using
	the QUERY opcode, it will still take the first arrival (the 
	freshest - by definition), fold up the socket and pass on the
	result.

	the DISCOVER opcode gets multiple replies (if any) and passes
	them on for "additional processing".  the resolver itself does
	not care - the application cares - and in this case, the application
	is the DNS.  

-- bill

---

From: [email-masked]
Date: Wed, 11 Jun 2008 12:08:09 +0000

> If you're the zone administrator, why didn't you send your DS record  

	my parent refused to take it..

> Or did your parent somehow publish a DS record without your permission?

	someone who claims to be my parent pubished a DS rr for my delegation,
	but its not mine.  (think alternate root constructs)

> servers without them), but not DS records?

	i may trust my parent to do so, when contractually bound.

> think this is what Olaf was suggesting.)

	logical OR is fine - IF - i can force the search order.

--bill

---

From: Edward Lewis <[email-masked]>
Date: Wed, 11 Jun 2008 08:55:30 -0400

>	anchor for higher up in the tree is for my neibours, not for

DNSSEC is not about protecting the zone admin, it's about protecting 
the recipient of the response.  The verifier, operating under local 
policy, is an agent of the (relying party's) resolver, not the 
(responding) server.

There is certainly confusion apparent in this answer.  Divide the 
world into the responding servers and subdivide into the authority 
servers and the cache servers.  Yeah, we have servers that do both. 
The other major segment of the divide is the (stub) resolvers.

When "I'm the zone admin" is said, I put my mind into someone 
managing an authoritative server.  There is no trust anchor involved. 
There is a "secure entry point" that I publish to interested parties, 
there is a key that is the seed for a DS record I expect to be put 
into my parent zone.  I don't do any verification.

I might have an expectation that verifiers will validate my zone's 
responses in a particular way.  But this it the Internet, the 
"clients" are not subservient to the "servers."  As the zone admin, I 
can present data, I can't determine how a recipient will use it, if 
at all.  I can't say "use only verified data from me" for instance. 
The notion that the server is not in control is more evident in 
routing, where the origin of a route advertisement has only limited 
control of how a remote end will transit networks to get to the 
origin.

When "I know what my trust anchor is" my mind shifts to the point of 
view of the relying party, the one that operates the verifier.  This 
is a different position, even if the functions of zone admin and 
relying party are lumped into the same corporate seat.  The job here 
is to accept data that is not part of an illicit attempt to provide 
false information, more or less.

What makes me furrow my brow in trying to understand Mark's point is 
"the trust anchor for higher up the tree is for my neighbors, not for 
my own zone."  If you are consulting a trust anchor, you aren't 
functioning as someone with "my own zone."

What I think is the issue here is whether you will accept an answers 
where there is a conflict between verification paths.  I.e.,  if a 
record set validates against the parent trust 
anchor/RRSIG+DS/RRSIG+DNSKEY/RRSIG+data and not against the child 
trust anchor/RRSIG+data - or vice versa.

A relying party could accept this data or it could drop this data. 
Either reaction is appropriate, one reaction is right (but that is 
impossible to know), and one reaction is preferred.  Which is 
preferred will depend on the relying party, not the zone admin, and 
the way in which they operate the network.

Without saying that a policy of using "only" the closest trust anchor 
is the preferred mode of operation, a policy of using "any" trust 
anchor is workable and appropriate at times, maybe even the majority 
of times.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Edward Lewis <[email-masked]>
Date: Wed, 11 Jun 2008 08:58:23 -0400

>	freshest - by definition), fold up the socket and pass on the

I don't buy that.  A resolver can listen to the socket for as long as 
it likes.  I don't believe that QUERY says "grab one and only one 
response" although that is how implementations choose (me making a 
sweeping statement there, I haven't looked at all implementations) to 
do it.

>	not care - the application cares - and in this case, the application

And with DISCOVER you get cash back!  (Oh, wait, that's from an 
advertisement somewhere.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: [email-masked]
Date: Wed, 11 Jun 2008 13:05:30 +0000

> sweeping statement there, I haven't looked at all implementations) to 

	perhaps you can re-read QUERY and educate me.  the implementations
	i looked at all do the "grab one and only one response" and the
	way i read the spec seems to support that view.

> >	not care - the application cares - and in this case, the application

	no cash back.. :)

--bill

---

From: Mark Andrews <[email-masked]>
Date: Wed, 11 Jun 2008 23:38:46 +1000

> If you're the zone administrator, why didn't you send your DS record  

	The above assumes that the parent has been given the DS
	records for my zone.  Just because that have it doesn't
	mean I trust them not to make a mistake or to be conned.
	Both of these events happen regularly today and I see no
	evidence that they won't happen once DS records are being
	accepted.
 
> servers without them), but not DS records?

	NS record in the parents are HINTS.  I want to know when they
	have been compromised and to not trust compromised records.
 
> separate trust anchor.

	Firstly "what seperate trust anchor"?  Secondly once you
	start publishing a trust anchor you took on the obligation
	for maintaining it and also notifiying the users of that
	trust anchor that it is going away when that happens.

> DNSSEC should tend towards not breaking, if at  

	The debugging tools we have today will handle broken trust
	anchors.  "dig +cd" is all you need to debug this.
 
> think this is what Olaf was suggesting.)

	I very much object to the default being the logical OR.
	That is the exceptional condition especially as is breaks
	existing practice.  What is now secure would become less
	secure.

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Wed, 11 Jun 2008 23:55:09 +1000

> policy, is an agent of the (relying party's) resolver, not the 

	It is protecting the recipient.  The trust anchor is configured
	into the validator.  As a admin I can be both a originator and
	a consumer.  Also being the admin I have complete trust in myself
	to keep the trust anchors I have configured up to date and
	correct in my validators.

	You can be a admin of multiple machines and multiple processes.
 
	Mark

---

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

Mark,

On Wed, Jun 11, 2008 at 11:38:46PM +1000, Mark Andrews wrote:
...
> 	trust anchor that it is going away when that happens.

Agreed, this is the current burden of early deployers. All this
discussion is based on the goal of making this a little bit easier.

> 	existing practice.  What is now secure would become less

This puzzles me.... please define what do you mean by less secure.

In what scenario a RRSIG that could be validated through a DS chained
over an upper TA and can't be validated through another "closer" TA is
less secure ? You have the crypto proof that the RRSIG is valid, you
only don't want to "see it" by not using the logical OR.

Better, please show a scenario that the use of the logical OR would
reduce the security.

AFAIK the logical OR put us definitely in a more stable situation.

Fred

ps. Please let's stop arguing that you don't trust you parent.... you
trust. The DNS namespace in hierarchical get over it or move to the
keywords business :-)

---

From: Alfred Hönes <[email-masked]>
Date: Wed, 11 Jun 2008 17:05:06 +0200 (MESZ)

>> think this is what Olaf was suggesting.)

That "logical-OR" *is* the core of the protocol.

>       existing practice.  What is now secure would become less

Sorry Mark,
you want a new protocol!

DNSSEC still makes use of classical (binary) logic a.k.a. set theory.
It does *not* use Fuzzy Logic.
(For non-initiated readers [overly simplified]: Fuzzy Logic replaces
binary truth values by probability measures.)

'OR' is the *only* solution that makes sense.

There's no such thing as '15% trust' or '99% trust' in DNSSEC.
There's only trust present or not.

As noted by someone other, the former is for humans, the latter
is for algorithms (in DNS and DNSSEC).

DNSSEC deals with only *finding* a chain of trust from a trust
anchor.  For efficiency and speed (that's what DNS seems to suffer
from most seriously anyway today, perhaps due to cache inefficiency
caused by needlessly short TTL values), all has been designed to
look for and stop after finding a verifyable chain of trust.  
There's no way to pass back a *degree of trust* from a DNSSEC
aware resolver to a (classical) stub resolver.

The DNS user needs a binary decision; either an RRset matching
the query (perhaps empty), or an error indication; and all that
as fast as possible.

If you really want to introduce and properly handle degrees of trust
you'd have to always perform search-in-breadth and establish much
more complex algorithms for the evaluation of the results than
ever envisioned for DNSSEC.  Not even X.50*, CMS, S/MIME, PKIX etc.
manage to properly deal with similar complexity.

Do not make DNSSEC even more complicated!
Leave all these Fuzzy ideas out of DNSSEC!
It would be overkill, and perhaps definitely kill DNSSEC
deployment at large; you'd have to wait for well-discussed and
stable algorithms capable of dealing with these Fuzzy ideas.

AFAICS, to specifically protect your local zones for local users,
only taking a local trust anchor into account, it is possible to
configure DNS 'forwarding' for those local zones, and operate those
(local) resolvers in "island mode" without recursive service.

Kind regards,
  Alfred Hönes.

--

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Wed, 11 Jun 2008 17:40:48 -0400

So you work for organization Example which cares about security. They
own your computer and configure it with a trust anchor for, say,
Example.com. When you are on the general Internet they are going to want
an RR set in *.example.com that is not signed by that configure TA or a
path traceable to that TA to be rejected. No matter what the standard
says, they will demand this feature in your resolver.

Donald

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Frederico A C
Neves
Sent: Wednesday, June 11, 2008 10:27 AM
To: IETF DNSEXT WG
Subject: Re: Confusion about trust anchors and DS records from the
parent?

Mark,

Fred

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 11 Jun 2008 19:43:24 -0300

On Wed, Jun 11, 2008 at 05:40:48PM -0400, Eastlake III Donald-LDE008 wrote:
> path traceable to that TA to be rejected. 

Let me try to understand, if you are the holder of example.com you
definitely control how do you sign and hand to your parent what they
accept. At the validators you control, supposing you are doing the
right thing, they'll be correctly configured. If in this situation you
get something not signed, definitely, drop it, because it is valid as
a 3 dollar bill. We are not talking about NOT having another security
path available. All this thread is about when you have more than one
path and at least one of then validate.

Fred

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Wed, 11 Jun 2008 21:15:29 -0400

Doesn't matter how many paths there are or whether or not you are the
"true" holder of the zone in the sense that people get to your data if
they start at root. If you really care about security, you want your
machines to never believe any RR sets in/under what YOU believe to be
your zone unless they are signed YOUR keys. That's it.

The fact that some RR set purporting to be in what you believe to be
your zone has some signatures that can be validly traced back to a TLD
or root or something doesn't matter for your policy. Your machines
should assume such stuff is bad. And it doesn't matter if there is a
second path back to your configured TA that fails. It's pretty easy to
forge signatures that don't validate and that's something an attacker
could add to the bad data they are feeding you.

Just how paranoid a user organization would have to be to want such a
policy is an interesting question. But eventually, if you assume
widespread deployment of DNSSEC, why would you bother to configure a TA
other than at root if you didn't have such a policy?

Donald

-----Original Message-----
From: Frederico A C Neves [mailto:[email-masked]] 
Sent: Wednesday, June 11, 2008 6:43 PM
To: Eastlake III Donald-LDE008
Cc: IETF DNSEXT WG
Subject: Re: Confusion about trust anchors and DS records from the
parent?

On Wed, Jun 11, 2008 at 05:40:48PM -0400, Eastlake III Donald-LDE008

Fred

---

From: Mark Andrews <[email-masked]>
Date: Thu, 12 Jun 2008 08:11:44 +1000

> This puzzles me.... please define what do you mean by less secure.

	I have exactly 1 path today.  I can get things wrong by not
	updating a trust anchor but I can't compromise myself (accept
	bad data) as things currently are.  If I go to a OR I get
	two paths.  One I totally control.  The other I don't
	control.
 
> only don't want to "see it" by not using the logical OR.

	Think about what happened to Comcast the other day and add
	changed DS records to the changed NS records.  Mistakes
	happen.  People get conned. 

> trust. The DNS namespace in hierarchical get over it or move to the

	I trust the parent to TRY to do the right thing.  I do NOT
	trust the parent to SUCCEED in doing the right thing.
	
	Mark

---

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

Mark,

On Thu, Jun 12, 2008 at 08:11:44AM +1000, Mark Andrews wrote:
...
> 	two paths.  One I totally control.  The other I don't

Being the child owner You are the one that control the NS and the DS
at your parent, and finally and most important You are the one that
control the DNSKEY set at the apex of your zone. If the key is not
there it'll not validate, but if it is there and there is an upper TA
that could validate it it's just being disruptive to not validate it.

The scenario we are plotting is the one that You the validating
resolver owner is not the owner of any of the 2 or more TA's
configured at it that starts covering the name but at different
levels.

I could see value on the current behavior but only in very specific
scenarios, I'm not arguing on for this to be outlawed, just to be put
as an option. The proposed behavior is the best one when you have the
root being signed after large TLD deployments already in place.

> 	happen.  People get conned. 

DNSSEC is not designed to solve administrative security problems. If
you have a bad registry/registrar or you are a lazy admin is not
DNSSEC that will save you.

> 	trust the parent to SUCCEED in doing the right thing.

So your argument is in the line that the current DNSSEC resolution
behavior will save you from a bad parent ?

Fred

---

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

> other than at root if you didn't have such a policy?

Because the deployment scenario that is in our horizon is showing
large TLDs deploying DNSSEC and the root is not signed and latter it
will get signed and at that time the OR behavior will make the
transition more stable.

We are not talking about private zones trusted by private entities, we
are talking about widespread deployment of DNSSEC on large zones that
are trusted by a large amount of resolvers. 

I'm not against the current behavior as long as it's optional and
could be signaled administratively for each TA.

Fred

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 12 Jun 2008 10:11:34 -0700

At 9:15 PM -0400 6/11/08, Eastlake III Donald-LDE008 wrote:
>But eventually, if you assume

There are many potential reasons. Remember that operations for DNSSEC 
are still at a very early stage.

- You install a TA for .org, and later the root is signed. You add 
the the TA for the root, not knowing if .org has sent its DS to the 
root, so you leave the TA for .org in your pile. You then forget it 
is there after .org has a chain from the root.

- You install a TA for .yourzone.com because you do not trust that 
.com will be competent about keeping its children up to date.

- You didn't understand the whole hierarchy thing and you thought 
"more TAs are good" because that is what you have been taught by a 
decade of using web browsers.

And so on. It is a bad idea to assume that every resolver admin will 
understand which TAs to install, and when to install them, and when 
to remove some of them.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Fri, 13 Jun 2008 09:39:15 -0400

Some or your reasons are reasons that OR would be good. Some of them are
reasons that OR would be fatal. It just shows that this must be local
policy and practical products will have to provide choice. OR is clearly
less secure.

Donald

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Thursday, June 12, 2008 1:12 PM
To: IETF DNSEXT WG
Subject: RE: Confusion about trust anchors and DS records from the
parent?

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Vixie <[email-masked]>
Date: Fri, 13 Jun 2008 14:16:19 +0000

> policy and practical products will have to provide choice. OR is clearly

hopefully noone has suggested that this not be overridable in local policy.

some (including me) have argued that OR is no less secure, and one argument
is that with multiple DS RRs, the expected policy is OR, since some can be
past, some can be future, some can be reserve.  (the difference between no
DNSKEY matching an available DS RR, vs. one that claims the same keyid but
does not match, is meaningless in the context of cryptovalidation.)

what we're looking for here is an "expected policy".  i think the expected
policy, the "default configuration" if you will, ought to be OR.  anyone who
wants AND or who wants ONLY should be able to specify that as a local policy.

please do not follow up to this note unless you disagree that the default
ought to be OR and the local policy ought to be settable to something else
like AND or ONLY; if you do follow up, please state reasons why this specific
default ought not be available to other people, since if it's available to
you then you can't really complain about its unavailability to you.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 13 Jun 2008 10:21:04 -0400

>policy and practical products will have to provide choice. OR is clearly

What's more relevant is "what is needed for interoperability?"

Count me as someone that believes "OR is *not* less secure" (than AND).

The reason lies in the definition of "secure." Having a foot in the 
operations world, I firmly believe the "OR" case is more secure in 
the sense that you will not be denied access by someone slipping in a 
bad signature of failing to have a current/correct value configured 
somewhere alone the way -  to cause one chain or another to choke.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 13 Jun 2008 08:40:55 -0700

At 9:39 AM -0400 6/13/08, Eastlake III Donald-LDE008 wrote:
>policy and practical products will have to provide choice.

Fully agree.

>OR is clearly

One definition of "secure" in this context is "allows authentication 
of a message if and only if the signature on that message chains to 
an installed trust anchor". With such a definition, OR is required.

A different definition is "allows authentication of a message if and 
only if the signature on that message chains to an installed trust 
anchor, where the chain checking is done by arranging all valid 
chains in order of length, and validation is done only using chains 
of the single shortest length".

The former definition is probably more sensible as a default 
definition. It prevents what could be a typical misconfiguration (an 
expired TLD TA and a properly-configured root TA) from making whole 
zones going bogus when those zones are, in fact, properly signed.

The latter definition might be appropriate for a small number of 
advanced and careful administrators in situations where they know 
that they will always be diligent and timely about their TA 
maintenance, and the admin explicitly want zones to go bogus if the 
admin is not diligent and timely.

--Paul Hoffman, Director
--VPN Consortium

---

From: Mark Andrews <[email-masked]>
Date: Fri, 13 Jun 2008 09:05:09 +1000

> will get signed and at that time the OR behavior will make the

	Large TLD will have to continue TA management for there zones
	for the foreseeable future.  They also have the resources and
	should have the expertise to do this forever.
 
> are trusted by a large amount of resolvers. 

	I think Donald and I are quite aware of what you are thinking
	about.  However we are looking at the safe default from a security
	perspective.  If you want to weaken your security we can't
	prevent you but we can atleast make you aware that you are doing
	something dangerous by making you do more work than the minimum
	of just adding a TA.

> could be signaled administratively for each TA.

	Which is the *wrong* default from a security perpective.

	Ease of admin shouldn't trump security.  That's what you are
	asking for.

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Fri, 13 Jun 2008 08:48:23 +1000

> .com will be competent about keeping its children up to date.

	So for that TA to be useful you have also had to have made
	a mistake in your key management.  You shouldn't be removing
	the old key before the new DS show up in the parent zone.

	Now please list the other threats that adding that TA can
	prevent.

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Fri, 13 Jun 2008 08:42:42 +1000

OR is *not* a reasonable default.  The reason for that is that
	when, not if, a bogus DS record is inserted into the chain of
	trust from the upper TA to your zone, your own validators will
	start accepting bogus data.

	Accepting bogus data is *much* worse than not accepting
	good data because you have failed to correctly keep your
	TA's up to date.  The later can be corrected by updating
	the configuration to have a current TA or by removal of the
	deeper TA.

	I can accept that people might want to also accept a higher
	TA but that *has* to be a explicit decision that they make.
	This is only good security practice.

	Remember we can't compare to the web as all root certs are
	equal.  DNS TA's have a heirarchical relationship to the
	data they are protecting.  All DNS TA's are not equal and
	never have been equal.

	Having data go stale and good data not validate is one of
	the risks we accepeted to prevent bad data reaching us.
	This is independent of whether it is a TA, DS or RRSIG which
	is stale.

	Mark

---

From: Paul Vixie <[email-masked]>
Date: Sat, 14 Jun 2008 02:14:24 +0000

> From: Mark Andrews <[email-masked]>
> Date: Fri, 13 Jun 2008 08:42:42 +1000
> 

one of the several reasons why i'm having trouble finding a way to agree
with this is that many validators will be inside networks which do not
also secure any of their own zones.  so the purpose which leads to the
desire you're arguing against is different from the purpose which leads
to the desire several of us are arguing for.

as a concrete example, consider a wireless isp who enables validation in
their caching/recursive dns servers.  they might install a trust anchor
for .SE and .ORG, and they might turn on trust anchor auto-tracking, but
they might or might not sign their own "wireless-isp.net" zone.  none of
us wants these potentially-someday-stale trust anchors for .SE or .ORG
to get in the way of DS RRs from the root zone.

the alternative in which "wireless-isp.net" is signed, and because .NET
is not signed there is a local trust anchor for "wireless-isp.net", and
some day .NET becomes signed and has a potentially-bogus DS RR for the
"wireless-isp.net" zone, is not what most people here are worrying about.
it's not a concern for three reasons: first, because bogus DS RRs from a
parent will be very rare; second, because a validator operator is very
likely to *know* when a parent of one of its own zones becomes secure;
and third, because if the default of OR is worrisome, they can override.

> 	This is only good security practice.

in terms of customer service costs, i can't accept nor recommend a default
that will cause my phone to ring when things fail for no apparent reason.
it's about a ten million times more likely that someone will fail to remove
a stale trust anchor than that a bogus DS RR will cause them to believe in
bogus data about their own zone.  and also, you're wrong about what is a
good security practice.  any seasoned security professional will tell you
that the strongest lock in the world won't protect you if you don't use it,
and the harder that lock is to use, the less likely that it will be used.

> 	data they are protecting.  All DNS TA's are not equal and

i didn't forget that.  i'd like the validation algorythm changed to say,
explicitly, that local trust anchors whether static or RFC5011-tracked
ought only to be used when one runs out of links on a chain of trust; in
other words, as a last resort, when the in-band chain of trust ends.  we
should not even notice local TA's that would allow us to terminate early,
until we've gone as far up the in-band hierarchy as we can, and then we
should come back down searching for local TA's in least-enclosing order.

> 	This is independent of whether it is a TA, DS or RRSIG which

i see no reason to accept that risk.  it's just not necessary.  i think
that if 4034/4035 fail to describe TA applicability then they are remiss,
and if they are amended to describe it, then it must be a default of "OR"
with a recommendation that "AND" or "ONLY" be specifiable local policies.

---

From: [email-masked]
Date: Sat, 14 Jun 2008 23:41:59 +0000

> should come back down searching for local TA's in least-enclosing order.

	here you and I disagree. I beleive (and I -think- I heard others state)
	that the local trust anchor, whether static or RFC5011-tracked
	ought to be used -FIRST-.

	if one -always- starts at the root and works down, the concerns
	previously expressed wrt bw & cycles are more valid.   starting w/
	the closest/least enclosing order puts you -much- closer to local
	support ... reducing the opex on third parties.

--bill

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 15 Jun 2008 09:21:33 +0200

> 	start accepting bogus data.

I do not buy this argument at all.

If bogus data (like NS or glue) are inserted in some parent of your  
zone, you are fried anyway.

On the other hand, if you have a TA configured, and then you add a DS  
(but keep the TA during the deployment time), and then forget to  
remove your TA at the first key rollover, then you must allow the DS  
that is ok to say things are ok.

    Patrik

---

From: Paul Vixie <[email-masked]>
Date: Sun, 15 Jun 2008 15:52:16 +0000

> 	here you and I disagree. I beleive (and I -think- I heard others
> 	state) that the local trust anchor, whether static or RFC5011-tracked
> 	previously expressed wrt bw & cycles are more valid.  starting w/ the
> 	closest/least enclosing order puts you -much- closer to local support
> 	... reducing the opex on third parties.

closest is most enclosing.  i think you meant "closest/most" here.

it's still OR, bill.  no amount of "failure to validate", from any direction,
will cause validation to fail in the above proposal, if there is so much as
one good trust path.  DNS is an internet subsystem, and as such, local TA's
are bootstrapping aids, like root hints or /etc/hosts files.  the bw & cycles
needed to track upward as far as possible before searching back down for TA's
is already going to be spent on validation of things that need & have no TA's.

however, if this proposal is made controversial by the top-down TA search,
then i'd support the following inferior alternative: "TA's whether static or
RFC5011-tracked ought to be used only if they cause validation to terminate
successfully, unless an explicit local policy is configured such that a TA
must correctly validate when a chain of trust passes through the TA's domain."

---

From: Mark Andrews <[email-masked]>
Date: Mon, 16 Jun 2008 09:28:30 +1000

> zone, you are fried anyway.

	So you don't believe that their will be configurations like this?

	zone mycompany.com {
		type stub;
		masters { .... };
		file "mycompany.com.stub";
	};

	trusted-keys {
		mycompany.com ....;
	};
 
> that is ok to say things are ok.

	No one is saying your senario won't happen.  What we are
	saying is that the worst result with ONLY is not getting a
	answer.  The worst result with OR is failing to detect
	deliberately bogus data.  This is the main design goal of
	DNSSEC (detect and reject bad data) and you want to throw
	it out the window.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 16 Jun 2008 13:15:02 +1000

> to the desire several of us are arguing for.

	Paul no one is arguing that OR should not be a option.  It
	should just not be the default option.  It is a *bad*
	default.

	If a site wants to secure its own zones it should be as
	simple as adding a trust anchor for its own zones.  It
	should not be add a trust anchor and by the way we need to
	remember to set this flag which says that this is a "ONLY"
	trust anchor otherwise we are leaving ourselves open for a
	attack via the registry system.  Such attacks have succeeded
	in the past and they will succeed in the future.

> to get in the way of DS RRs from the root zone.

	This all reminds me of the BIND 4 days where named would
	"load" a zone despite errors in the master file.  Errors
	in configuration files NEED TO BE FIXED not GLOSSED OVER.
	In the end they will come back to bite the operator.

	Everytime we have done this it has resulted in problems
	that would have been avoided if the software had just made
	the failure visible in addition to logging the problem.
	We know from experience that logs only get read when there
	is a visible problem.

> that will cause my phone to ring when things fail for no apparent reason.

	You mean to say "configured trust anchor is stale" is not a
	apparent reason.

	I'm much more worried about what happens when we fail to stop
	a attack because the defaults were insecure.

	What is so difficult about something like:

	trusted-keys {
		"se" accept-parent-ds 257 3 5 "..."; 
			or
		"se" accept-higher-trusted-keys 257 3 5 "..."; 
	};

	Also do you really want "dlv.isc.org" to validate back to
	a trust achor for ".", by default, when there is a explicit
	trust anchor for "dlv.isc.org"? 

	I'm sure "." and "org" will attempt to do the right thing
	but the registration for "isc.org" will become a inviting
	target if the default is changed.  Similarly for any other
	dlv tree.

> and the harder that lock is to use, the less likely that it will be used.

	What's hard about adding a extra mode flag when you configure a
	trust anchor?
  
> with a recommendation that "AND" or "ONLY" be specifiable local policies.

	I strongly disagree.

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 16 Jun 2008 05:52:54 +0200

> 	in the past and they will succeed in the future.

And this is where we disagree, and I do not think we will come much  
further in this discussion.

I think, as you know by now, that it will be much more common to sign  
the DNS from leaf towards the root. This implies TA will be added  
first, and then DS later. Default operation will because of that be to  
"turn on DNSSEC" which will be to include a TA. And then forget it.

A much more rare operation will be to add a TA that is to explicitly  
override data in parent zone. If you do so, then I definitely think  
one have to add the TA _AND_ turn on the ONLY setting.

    Patrik

---

From: Brian Dickson <[email-masked]>
Date: Mon, 16 Jun 2008 00:29:55 -0400

> 	in the past and they will succeed in the future.

It seems to me, and please tell me if I'm wrong, that there are two 
situations which the current things available,
can't readily distinguish:

(1) A stale TA, where the originator of the TA-signed data has rolled 
keys, or otherwise published new TA or DS for authenticators to use,
and a valid thing to authenticate that validates per the "other" TA 
(e.g. signed root and proper delegations via DS)

(2) A non-stale TA, and the TA-signed data is still valid and validated, 
with a rogue DS injected somewhere which hijacks a portion of the DNS 
below it that would also validate based on the rogue DS.

What seems to be missing, is a way for a validator to be advised via 
signed-with-the-old-TA data that effectively marks the TA as stale.

The question is, how long would such a record need to exist and be 
provided along with SOA data for a given zone?

Consider two scenarios:

(1) the root eventually gets signed (by eventually, meaning in a 
not-unreasonable length of time, as measured in political intervals - 
2-5 years).
(2) the root never gets signed

In case 1, the typical need for TA distribution for zones is likely 
relatively rare, with a small number of key-rollover events.
In case 2, TA distribution and key rollover is a big deal, and likely to 
occur, if not often, at least a number of times.

If case 1 is likely, then "for a long time" or "forever" is reasonable 
for publishing revoked-TA records (signed with the TA itself).
If case 2 is likely, then there is more of a reasonable requirement for 
anyone managing TAs to be aware of their existence and to handle 
failures properly.

Does the idea of TA-revocation help disambiguate these cases?

If so, then perhaps "OR" is not actually needed, and Mark's assertions 
are correct, but also lacking in the mechanism for properly identifying 
stale TAs in such a way as to be securely and validly be bypassed *only* 
if the zone admin for the TA publishes data to that effect - something 
that the zone admin not doing would enable simple TA set-up, and with 
doing, enabling sane default behavior for everyone whose view is more 
liberal on security than Mark's.

(No offense to anyone involved in the discussion is intended, even by 
accident.)

I can see both sides of the argument, and agree with both of them.
It is in fact a paradox caused by the ambiguity of the fact that both a 
TA and a DS can be used to sign a zone, with no way of knowing *why* one 
works and the other doesn't, if they don't both validate.

Brian

---

From: Paul Vixie <[email-masked]>
Date: Mon, 16 Jun 2008 05:38:26 +0000

> 	You mean to say "configured trust anchor is stale" is not a

yes.  because i do not expect validator operators to configure trust anchors
at all, just like they don't configure stub zones at all, they will find their
own zones via the registry system's NS RRs and they will decide whether or not
to trust the keys used to sign those zones via the registry system's DS RRs.

it's possible that rdns' ought to always configure stub zones for all "local"
zones, in case the registry system is ever unreachable or corrupt.  and it's
similarly possible that vrdns' ought to do RFC5011 tracking of the trust
anchors for "local" zones, for the same reasons.  but since many rdns or vrdns
don't have any "local" zones, and those that do, add and drop them over time,
and there is no clear definition of what "local" means, and no widespread
automation of any of this, i'm expecting vrdns and secure authoritative dns
servers to be like ships in the night.  in the common case, no trust anchors.

in the uncommon case where a trust anchor is known, it's either because the
registry system did not have the ability to convey DS RRs at the time a vrdns
wanted to validate something, or because of operator conservatism along the
lines you're describing ("maybe the registry will become corrupt somehow, and
i'll start believing bad data about my own zones").  i believe that in this
uncommon case where a trust anchor is known for something other than a TLD or
for the root, the conservative operators will be the ones who know to set the
ONLY option, and that the ahead-of-the-registry operators will be the ones
most likely to never deconfigure a trust anchor after the registry starts
spewing DS RRs.

since usability is one of the major remaining problems in DNSSEC deployment
(the other two being: lack of motivation, and lack of political will to sign
the root and the TLDs), i have heightened sensitivity as to things that make
DNSSEC even harder to use, and even more likely to fail, and fail silently,
with no local expertise as to what's probably gone wrong, time and money lost,
BIND taking the blame for it, and so on.

> 	What's hard about adding a extra mode flag when you configure a

i was going to ask you the same.  above, i explained why the onus ought to be
on the conservative operators rather than on the early-adopting operators.

> > with a recommendation that "AND" or "ONLY" be specifiable local policies.

i suggest that if IETF thinks this is a local policy issue, unfit for mention
in a dnssec updates document, that ISC punt it to the BIND Forum to decide.  i
would prefer that there be an explicit IETF standard so that BIND could just
follow that.  implementors must never "legislate from the bench."  i think we
have each made our case strongly, and if IETF can't discover a position based
on what they've heard on this topic, each implementor should seek the counsel
of its own user community.

---

From: Robert Elz <[email-masked]>
Date: Mon, 16 Jun 2008 18:17:55 +0700

Date:        Mon, 16 Jun 2008 09:28:30 +1000
    From:        Mark Andrews <[email-masked]>
    Message-ID:  <[email-masked]>

  | 	No one is saying your senario won't happen.  What we are
  | 	saying is that the worst result with ONLY is not getting a
  | 	answer.

That is, the network doesn't work.   I cannot imagine a much worse
situation.   Either I cannot use the net (which by the time DNSSEC
is used by anyone who matters is likely to be used for all communications
of all kinds in the world) to report the issue, to ask what to do
about it, or if I manage to get my message out, no-one can find my
DNS (because of some mis-configuration) to reply to me.

  |     The worst result with OR is failing to detect
  | 	deliberately bogus data.

Tell me how I do it?   Note, I am not your parent, or anyone up your
tree of delegations, I'm just some clown wanting to attack you.

Assuming you have "or" configured, and I know that, what is the mechanism
I use to cause a problem, and who is affected?

If your answer starts with "trick your parent to ..." then I continue
that with "delete your delegation completely" or "assign your delegation
to me", after which you no longer exist in the first case, or I am now
you in the second, and what I put about your domain is correct by DNS
definition (it may not be what you wanted, but in the DNS, authority
flows from the top, if a domain is delegated to me, it is mine, at least
until it is moved again.)

So, please avoid scenarios where I cause someone to alter your NS or DS
records in the delegation zone, if I can manage to do that, DNSSEC
won't help in any way at all (and nor should it.)

You can however assume that I manage to find an accidentally misconfigured
parent zone, or similar - given that, tell me how I go about introducing
bogus data (or denying the existence of data that should exist).  You also,
of course, need to assume that dnssec is deployed and working correctly, in
all aspects except some mis-config over which I, the attacker, have no
control.  (You can assume I can control my own data, and delegations to
it, of course, if that somehow helps the attack.)

If you can show a plausible scenario where an attack would work, then perhaps
people might be more willing to listen, but so far all you're alluding to
is accidental mis-config by parents (I'm not even sure what they could do
that would have any of the problems you seem to be worried about, but that's
not important right now).

  |     This is the main design goal of
  | 	DNSSEC (detect and reject bad data) and you want to throw
  | 	it out the window.

I agree with something Paul said a few messages back - I'll say it again in
other words (I don't think I am misstating the position).

The biggest enemy we have to any kind of security on the internet is the
people who keep insisting that the security be perfect.

It can never be, and continually looking for ways to make it perfect both
delays the introduction of anything real, and causes the eventual "solution"
(if one ever appears) to be so complex as to be unusable.

All we need is to make things a bit more difficult than it is worth attacking
for the benefits to be achieved from the attack.  Or in this situation, if
I can detect most easily introduced bad data (or make it too difficult for
most people to try to introduce any) then we have succeeded.   That it
remains possible in some difficult to achieve  manner to occasionally
introduce some bad data that might be able to fool some people is not 
necessarily a huge defect - the various costs all need to be examined and
trade-offs made.

For most people, this is equivalent to using a $5 lock with a $2 chain to
secure your bicycle - it won't necessarily stop everyone who might be
determined to steal the thing, but it's enough to defer most casual thieves.
It's also cheap enough, and easy enough to use, that people (many, or even 
most) are willing to actually implement it.

What we don't want is $5000 multi-key locks, and $1000 toughened tungsten
chains with extra capacity to lock down the wheels as well as the frame,
all of which weighs too much to carry, takes half an hour to attach, all to
protect something worth less than the cost of the protection.

Nor do we want something whose idea of protection is to blow up the
bicycle if someone attempts to make off with it - that certainly would
prevent it being stolen, but to me, the end result would be the same.
Protection that causes things to fail is worse than no protection at all.

Of course, if you have something worthy of special protection, then you
can take extra steps - those people may want the very high grade bicycle
lock, or the "only my trust anchor" configuration - but they're far and
away the minority.   The default configuration should be for the ordinary
user, with nothing very special worth protecting (or attacking) in any case,
and no need for excessive security levels - but who do want things to
keep on working, if at all possible.

Almost finally, all your concerns seem to be about people attacking things
so you can no longer believe your own data.   For local use, if that's
even remotely possible, why would you consider using the DNS for your
own names at all?  Use something safer instead.   I do on some of my
systems, not because of huge security concerns (what I use instead is
probably less secure) but for robustness - I don't need DNS servers
running in order to operate, and to me (for some things) that's important.

But I always thought DNSSEC was mostly intended to allow me to verify
data about your names, not so much about my own.   How does any or your
planned configuration allow me to more accurately determine which is
your correct data and which is not, given I neither have, nor ever will
have, anything special configured about your zone?   That's the kind of
thing DNSSEC is really trying to make secure - to allow me to determine
which answer you authorised, and which you did not.

Lastly, do remember, all this multi trust anchor stuff is happening only
because of the difficulties getting anything rational done at the root (and
other similar kinds of zones.)   If it weren't for that, and DNSSEC deployment
came top down, we would have had only one trust anchor, at the root,
and everything else would have flowed from there.   All this other nonsense
is simply caused by people trying to live with the realities, ad yet still
get whatever benefit they can out of dnssec.  Practically that's needed, but
it shouldn't be driving the security model.

kre

---

From: Edward Lewis <[email-masked]>
Date: Mon, 16 Jun 2008 09:52:08 -0400

>		file "mycompany.com.stub";

 From my experience, there are a few things wrong with that.

My internal infrastructure will see the inside split-DNS version of 
my zone, which I won't be bothering to sign because both the 
authority and iterative servers will behind the same security wall - 
the firewall(s) I have, or even within the same VPN.  If I bothered 
to tighten up all of the internal infrastructure my opex costs would 
be prohibitive and I couldn't make use of ActiveDirectory.

If I bothered to sign my external split-DNS zone, I certainly would 
not want that "leaked" back inside to my infrastructure.  I mean, 
signed or not I don't want leaks.  (I've seen situations at past 
places where there the value in the A record HAD TO BE different 
inside and outside.)  But instead of being happier to see signed 
records, I would be sadder.

Now, it might be that it seems like my design falls because I'm 
hardening the shell and not the insides.  But that is the way many 
sites operate.  The reason is, if the shell cracks, you have problems 
but you also know where to fix it.  If you secure up the inside, it's 
often so complex you don't know if there's a compromise in the 
thickets.  If there is a non-DOS attack, it's probably trying to get 
into my sensitive database.  I'd rather be able to fight that without 
having getting tangled in all the other security reactions.

I think I asked for this quite a while ago - a null key I could put 
in my zone apex so that if an iterator came down from a (signed) 
root, (signed) TLD, and saw that there was an external split-DNS zone 
I could get it to accept an unsigned internal split DNS zone.  This 
comes to mind because I never could understand what the rationale was 
for signing the inside split-DNS zone.