Subject: Re: I-D ACTION:draft-ietf-dnsext-rollover-requirements-00.txt

From: Geoffrey Sisson <[email-masked]>
Date: Thu, 23 Feb 2006 19:36:09 +0000

Ben Laurie <[email-masked]> wrote on 23/02/2006 19:16:42:

> 5.3 - is "SHALL" (as opposed to "shall") a word?

Equivalent to "MUST" (RFC 2119).

Geoff

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

---

From: Russ Mundy <[email-masked]>
Date: Fri, 24 Feb 2006 17:23:08 -0500

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

see in-line:

On 2/23/06 at 7:16 PM -0000, Ben Laurie <[email-masked]> wrote: 
>[email-masked] wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>> This draft is a work item of the DNS Extensions Working Group of the IETF.
>> 
>>  Title       : Requirements related to DNSSEC Trust Anchor Rollover
>
>Comments:
>
>Emergency Trust Anchor Rollover:
>
>  "Any security-aware resolver
>   using those RR(s) as Trust Anchor(s) must quickly remove them from
>   use by the resolver."
>
>Surely not - what must happen is they must start using the new keys
>and stop using the old ones.

The current wording may need improved but I think that your suggested change
infers that there _will_ (or MUST) be new keys available at the time that the
'old' keys should no longer be used, e.g., 'old' keys have been compromised.
While I agree that having new keys in place when old keys are removed is the
most desireable state but I believe that there is a real possibility that a
zone may not have new keys available so that the zone can no longer be
operated as signed.  In that case, the security-aware resolver should stop
using the old key as a TA and treat everything under that hierarchy as _not_
signed.  In other words, the TA should no longer be used even though a new key
is not available.  Do you have some wording suggestions?

>
>Normal or Scheduled Trust Anchor Rollover:
>
>  "Operators of security-aware resolvers using RR(s) from that zone as
>   Trust Anchors need to acquire new and remove revoked Trust Anchors
>   at roughly the same time as the signed zone issues or revokes
>   RR(s)."
>
>Actually the requirement is that they don't use revoked ones after
>they are revoked and do use new ones. Why is this different? Because
>it allows resolvers that are offline for an extended period to comply.

I agree that this definition doesn't mesh particularly well with 5.5 but I
don't think that they conflict either in that when a system is 'returning from
offline' there should be an effective, secure method for it the resolver to
use only valid TAs.  Do you have some suggested words here?

>5.3 - is "SHALL" (as opposed to "shall") a word?

What Geoff said "Equivalent to "MUST" (RFC 2119)."

>
>5.9 - "Information about the issuer's view of that state of Resource
>   Records used as Trust Anchors" - should "that" be "the"?

Right, got it, thanks.

>
>also, a metacomment - some of the requirements seem to have ended up
>hidden in the definitions (such as those I comment on above).

Well there was some discussion among the editor team about things that should
be definitions and things that should be requirements.  For the most part, the
requirements section are things the editor team received as directed in the
last WG meeting (mail list, direct mail & WG meetings).  The definitions were
written to explain terms that were included in the requirements that did not
have definitions (or not enough of a definition) in rfc4033.  

It is certainly possible that some WG members believe (like Ben) that some (or
lots of) things from the definitions section should be revised & moved to the
requirements section.  If you believe this to be the case, please speak up &
provide suggested wording for the 'new' requirement.

>Cheers,
>Ben.

Thanks a lot for your review & input,

Russ