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

[Mohan Parthasarathy <[e-mail]>]

On Wed, Feb 8, 2012 at 6:22 PM, Mark Andrews <[e-mail]> wrote:
>
> 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 <[e-mail]> 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 [phone]
>>
>> 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.
>
Right, but what I wrote was not Absolutely wrong, if you assume that
there will at least be  a root trust anchor configured,  But it might
be worth clarifying the first and third bullet above for Insecure.

-mohan

> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone]                 INTERNET: [e-mail]
_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext