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

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

> At 11:00 PM 6/5/2008, Mark Andrews wrote:
> 
> >> On Fri, Jun 06, 2008 at 10:19:30AM +1000, Mark Andrews wrote:
> >> 
> >> >     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.
> >> 
> >> 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.
> >
> >        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.
> 
> I delayed a response hoping you'd explain why you think this is a "dangerous 
> policy".  

	Please look back at my previous usage examples.  They all give "bad"
	results if you follow the DS rather that rejecting the answer when
	it fails to match a configured TA.
 
> Your approach is a violation of the "be generous in what you accept" principl
> e.   Granted that for "security" reasons, we sometimes violate this, but I do
> ubt 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 zo
> ne that doesn't validate the RRSet.
> 
> Look, the in-band signalling of whether a trust anchor for a zone is still va
> lid (RFC5011 for example) is, due to the nature of DNS, a very loosely couple
> d protocol.  It's possible  the termination of publication of separate trust 
> anchors for the zone following the security adoption (e.g. publishing of DS r
> ecords) of a signed subzone by its parent could be missed by a resolver, eith
> er 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 SE
> P DNSKey that signs the apex DNSKey RRSet while still having a DNSKey trust a
> nchor that no longer is part of that RRSet.  Under your rules, that zone, alt
> hough validly signed, would be considered bogus.

	Correct.  But you have to ask "Why was the TA configured
	when there is a higher TA configured and a valid trust chain
	from that TA despite knowing that TA tracking is error
	prone?"  This is the long term state of validator management.

	Extra TA are not added on a whim.

	People are complaining at the moment because were are in a grow
	from the bottom expansion.  Islands are being joined together
	etc.  This is not long term behaviour.  It will switch to
	top down as the TLD's start to sign delegations.  People will
	remove TA's that are unnecessary as that reduces the maintenance
	effort required.

	It will be test and remove.

> Vixie posted:
> >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.
> 
> I can't parse this.  The first part says "I want to use the trust anchor", bu
> t 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 me
> an - "If I have trust anchors configured for a zone, then I want the option t
> o try validation with them and only them and if any trust anchor validates, t
> hen the zone validates otherwise it does not validate regardless of whether i
> t 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 validati
> on) as a local policy because it increases the fragility of the system withou
> t 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 hop
> e 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 addin
> g the option to the text of the revision.
> 
> Mike
> 
> 
> 
> 
> >        Mark
> >
> >> A
> >> 
> >> -- 
> >> Andrew Sullivan
> >> [email-masked]
> >> +1 503 667 4564 x104
> >> http://www.commandprompt.com/
> >-- 
> >Mark Andrews, ISC
> >1 Seymour St., Dundas Valley, NSW 2117, Australia
> >PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
> >
> >--
> >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/>
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
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/>