Subject: Re: [DNSOP] Questions on section 3 of draft-ietf-dnsop-dnssec-trust-anchor-02

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 09 Mar 2009 10:58:14 -0400

We have had an off-line discussion with Paul on how to address his comments
and this is the result of that discussion.
New version will show up RSN.

At 13:55 06/08/2008, Paul Hoffman wrote:
>Greetings again. Section 3 of this document says:
>    If any of the steps above result in an error, the validating resolver
>    SHOULD log them.
>
>...and then what? Continue on merrily as if the priming worked? Just 
>logging the error seems like undershooting the security of using trust anchors.
>
>Later in that section, it says:
>    If a validating resolver is unable to retrieve a signed DNSKEY RRSet
>    corresponding to a trust anchor (i.e., prime the trust anchor), it
>    SHOULD log this condition as an error.  Inability to prime a zone's
>    trust anchor results in the validating resolver's inability to
>    validate data from the corresponding zone.  The validating resolver
>    SHOULD treat this zone as bogus.
>
>It is not clear why not being able to get the DNSKEY RRSet is more 
>serious (and thus worth bogofying the zone) than the validating 
>steps not working.

The new version of the draft will have an explicit pointer to
RFC4035 saying that TA processing errors should be treated the
same way as DS processing errors.

>Further, the last sentence has a "SHOULD" but doesn't say under what 
>circumstances that a resolver can ignore the "SHOULD". Why isn't this a "MUST"?

You are right the new version says "MUST"

thanks for your comments.

         Olafur