Re: [dnsext] Reminder: two WGLC closing in one week

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Michael StJohns writes:
> I think you're getting too much into the minutia of arguing about how things a
> re done with DNAME if you apply the "rules" and not enough into thinking about
>  whether or not the rules for DNAME need to be different or clarified....
> 
> 
> At 02:18 AM 9/23/2008, Mark Andrews wrote:
> 
> >> 
> >> So the last question is what goes on when you have the same three queries -
>  exc
> >> ept the last one now validates, and the DO bit wasn't set from the stub res
> olve
> >> r? (e.g, I won't understand the lack of AD bit)
> >
> >        You return the answer.
> > 
> >> The simple answer would be to return the three RRSets - but is that the rig
> ht a
> >> pproach or only one of several correct approaches?  
> >> 
> >> I could argue the paranoids point, that once the answer becomes secure, unl
> ess 
> >> it becomes securely unsecure (by proving there's no DS at a delegation poin
> t), 
> >> then the final answer must either be secure or bogus.  In other words, if I
>  get
> >>  a referral via a CNAME or DNAME into unsecure space, then the final answer
>  sho
> >> uld be "bogus".
> >
> >        No.  Everything that is not at or below a TA is deemed to
> >        be insecure.
> 
> Actually, there is a pretty large difference in considering security between:
> 
> Insecure:  Someone I trusted told me that data doesn't need to be signed (e.g.
>  secure delegation to an unsecure zone)
> and
> Unknown: I have no idea whether or not that data should be secure - it's not u
> nder a trust anchor *I KNOW ABOUT* - and because of that I can't make useful s
> tatement about its actual security.

	As far as your validator is concerned it *is* to treat the
	data as insecure.  This is what RFC 4035 says to do with
	it.  There are no "if", "maybe" or "what if".  This is
	clearly stated.

   Insecure: An RRset for which the resolver knows that it has no chain
      of signed DNSKEY and DS RRs from any trusted starting point to the
      RRset.  This can occur when the target RRset lies in an unsigned
      zone or in a descendent of an unsigned zone.  In this case, the
      RRset may or may not be signed, but the resolver will not be able
      to verify the signature.

	If a name is not under a TA then the first sentence is met.
	The second and subsequent sentences give the non trivial
	example of when the first sentence can be met.  It's not
	"This will occur", it's "This can occur" and "In this case".

	Perhaps we should have split this into two paragraphs and
	as you have failed to see the trivial case add it.

   Insecure: An RRset for which the resolver knows that it has no chain
      of signed DNSKEY and DS RRs from any trusted starting point to the
      RRset.

      This can occur when the target RRset lies in an unsigned
      zone or in a descendent of an unsigned zone.  In this case, the
      RRset may or may not be signed, but the resolver will not be able
      to verify the signature.  Alternatively this can occur when there
      is no trusted starting point at or above the name.

	The only time a record is unknown is prior to attempting
	to validate or when you can't reach the servers to get the
	DNSKEY/DS in the chain that would allow you to validate.

   Indeterminate: An RRset for which the resolver is not able to
      determine whether the RRset should be signed, as the resolver is
      not able to obtain the necessary DNSSEC RRs.  This can occur when
      the security-aware resolver is not able to contact security-aware
      name servers for the relevant zones.

	You can ALWAYS reach you TA's as they are part of the
	validator's configuration.  Therefore you can ALWAYS validate
	data which is not under a TA.  That validation ALWAYS returns
	insecure.

	If you use DLV then you need to check with the DLV registry
	to detemine if the name is secure or not.  I have exactly
	the reverse arguement when someone complained that we should
	be returning insecure when the DLV lookup timed out.  With
	DLV you have to prove that the name is not covered by a DLV
	record.

	However if you still have a island that is not covered by
	either a TA or a DLV record then the records are insecure.

> >> The above is different than the secure delegation to an unsecure zone:  The
>  sig
> >> ned delegation to an unsigned zone is controllable by the delegator.  The s
> igne
> >> d CNAME or DNAME referral to an zone carries no information about whether t
> he r
> >> eferrer/signer believes the target zone/name should be signed.  
> >>
> >> I'm trying to reconcile this with the general policies on how data is retur
> ned 
> >> from a validating recursive resolver to a non-DNSSEC aware stub resolver.  
> The 
> >> VRR returns an RCODE 2 for any data below a trust anchor it can't validate 
> (bog
> >> us), and returns the data which has no superior trust anchor (unknown),
> >
> >        No, it is NOT unkown.  It is insecure.  You are attempting to introdu
> ce
> >        a state which does not exist.
> >
> >        secure -> passes validation
> >        insecure -> no TA or there is a insecure delegation from a secure zon
> e.
> >        bogus -> fails validation
> 
> yeah - we've had this discussion a number of times. If I have no basis on whic
> h to make a security determination, it is indeterminate or unknown. In VRR pro
> cesing, that generally means the data is passed along with the AD bit off whic
> h is no different than the result for insecure data.  The fact the end result 
> is identical from the POV of the querier does not mean the trust states are id
> entical.
> 
> With respect to the current problem:
> 
> If the middle chain is insecure (e.g. I did CNAME/DNAME into a zone below I tr
> ust anchor the VRR has, but that is below a secure unsecure delegation), is th
> is more trustworthy than if the middle chain resolved to an RRSet that had no 
> superior trust anchor?
> 
> Again, paranoid's argument suggests that I might consider the former a non-bog
> us answer and the latter a bogus answer given general DNSSEC principles.

	Go read the definition of INSECURE in RFC4035.

> >> returns
> >> the data it was able to validate (secure), and returns the data which was b
> elo
> >> w an unsecure delegation point (unsecure). 
> >> 
> >> I'm not sure I can argue that a DNAME or CNAME into an unknown/unsecure zon
> e fr
> >> om a secure zone is equivalent to an unsecure delegation from that secure z
> one 
> >> to a subsidiary, because the target of the DNAME/CNAME can change the DNSSE
> C st
> >> atus at any time after the CNAME/DNAME is published.  Unfortunately, I can'
> t se
> >> e any way of encoding the DNAME/CNAME signers expectation of security for t
> he t
> >> arget zone in the current definitions.
> >
> >        Each QNAME when following a CNAME chain is independently
> >        validated.  When you return the final answer you look at
> >        all the components to determine whether the final answer
> >        is secure (AD could be set if requested) or not.
> 
> Agreed, but the current argument is whether or not there is a meta policy that
>  needs to be applied and not just a min() of all of the independent chain resu
> lts.  What you're identifying is the obvious, but possibly incorrect/insecure 
> approach.
> 
> > 
> >> So if I follow the principal of "if it started out secure and I can't prove
>  it 
> >> was meant to be unsecure then it should be bogus if I can't validate it" wh
> ich 
> >> we follow for on-tree delegations, shouldn't I follow it for off-tree deleg
> atio
> >> ns?
>
> >        Except you can validate that it is insecure.
> 
> Actually, you can't.  If the middle chain is not under a trust anchor (or rath
> er if the resolver holds no trust anchor) no validation is possible and an att
> acker can literally do whatever he wants with the result data.   And the fact 
> of the AD bit being set or not is mostly irrelevant - the end system is still 
> going to see the data.  If the middle chain IS under a trust anchor - there ha
> s to be an unsecure delegation for an attacker to get traction.  

	Name not under TA => INSECURE.

> The more I think about this, the more I begin to believe that for consistency,
>  if you start under a trust anchor, you better be able to end under a trust an
> chor and that all chains must be able to be validated/authenticated UNLESS you
>  find an unsecure delegation along the way.    Otherwise you get this weird st
> ate where the originator of the data thought he was doing the right thing (a s
> ecure DNAME referral into a secure zone), but that the resolver could find its
> elf returning data that was actually bogus (because it was lacking a trust anc
> hor for the referred zone and an attacker got to it).
> 
> The tradeoff here is that doing it this way makes the combination of DNSSEC an
> d DNAME or off-tree CNAME less useful.  But what's the right answer from a sec
> urity perspective?  Do we address this by forcing a resolver behavior, or simp
> ly by noting the security issues with off-tree DNAME/CNAME referrals?
> 
> I obviously don't think the simple answer is as correct as you think it is.  T
> hat's a matter of opinion and the one for discussion.
> 
> Mike
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]

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