Re: [dnsext] Issues in WGLC of dnssec-bis-updates

In message <a06240800cb58cc29d79a@[172.17.20.117]>, Edward Lewis writes:
> At 15:27 -0800 2/8/12, Mohan Parthasarathy wrote:
> >On Wed, Feb 8, 2012 at 3:05 PM, Mark Andrews <marka@isc.org> wrote:
> 
> >>
> >>  Step 1 of validation.
> >>  Is there a potential covering trust anchor?
> >>         Yes.  Goto step 2.
> >>         No.  Mark as insecure.
> >>
> >>  Step 2 ....
> >>
> >From RFC 4033:
> >
> >Insecure: The validating resolver has a trust anchor, a chain of
> >       trust, and, at some delegation point, signed proof of the
> >       non-existence of a DS record.  This indicates that subsequent
> >       branches in the tree are provably insecure.  A validating resolver
> >       may have a local policy to mark parts of the domain space as
> >       insecure.
> >
> >So, I don't understand what you mean.
> 
> What Mark wrote is consistent with that paragraph.  Not complete, but 
> consistent.
> 
> Look at a path through the namespace:
> 
>      o      = root
>      |
>      o      = tld
>      |
>      o      = example
>      |
>      o      = www
> 
> Let's say that "tld." is a cut point.
> 
> Case 1 - if there are no trust anchors at all, then everything is "insecure."
> 
> Case 2 - if there is a root trust anchor and there is provably no DS 
> record for tld., then all names in the tld. domain (not just the 
> zone) are provably insecure.
> 
> Case 3 - (as in case 2 up to the BUT) if there is a root trust anchor 
> and there is provably no DS record for tld., BUT there is a trust 
> anchor for example.tld. and www is not a cut point.  In this case you 
> can validate sets owned by www.example.tld.  "Insecure" is never an 
> outcome.  The possible outcomes are "bogus", "valid" (or whatever 
> "good" is called), and a service failure if some record cannot be 
> retrieved.
> 
> Case 4 - trust anchors at root and tld.root and no cutpoints without 
> a DS, then you'll never see insecure.
> 
> (I hope I have this right.)
> 
> And only "Bogus" is bad, no data is returned for Bogus and Service 
> Failure.  Data is returned for Insecure and Valid.
> 
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis
> NeuStar                    You can leave a voice message at +1-571-434-5468
> 
> 2012...time to reuse those 1984 calendars!

Insecure is data that validator *knows* is cannot cryptographically verify.
This may be because:
* there are no suitable trust anchors to attempt to verify with.
* there is a insecure delegation (provable no DS record) in the path.
* there is a secure delegation but no algorithm support in the path.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext