Subject: Re: WGLC on rollover-requirements and trustudpate-timers

From: Robert Story <[email-masked]>
Date: Thu, 12 Oct 2006 16:09:06 -0400

OMK> On 25Sep 2006, at 10:00 PM, Olaf M. Kolkman wrote:
OMK> > This message starts the working group last call for two documents
OMK> >
OMK> >             draft-ietf-dnsext-trustupdate-timers-04
OMK> >           Automated Updates of DNSSEC Trust Anchors

Sorry for the late review. I have read this draft, and I support it going forward, but I think a few things need to be addressed before sending it on.

2.3.  Remove Hold-down

   A new key which has been seen by the resolver, but hasn't reached
   it's add hold-down time, MAY be removed from the DNSKEY RRSet by the
   zone owner.

I think this 'MAY' should be 'may' (or could) since it is talking about the zone operator and not the resolver. Actually, the sentence should probably be stricken entirely, and the next sentence reworded:

   If the resolver sees a validated DNSKEY RRSet without a new key that
   has not reached it's hold-down time, it waits for the remove hold-down time
   and then, if the key hasn't reappeared, SHOULD discard any information about
   the key.

Also, I don't see this represented in the state table in section 4. That
table shows a new key that hasn't reached it's hold-down time ('AddPend'
state) transitioning back to the 'Start' state for missing key
('KeyRem' event). Maybe the state chart should have a 'KeyRem' event
transition an 'AddPend' key to the 'Removed' state.

4. State Table

This table shows the 'Revoked' state requiring a 'RemTime' event for a
key to transition to the 'Removed' state. Section 2.1 clearly states
that revocation is immediate, with no timer involved. With this event
remove, the 'Removed' state has no data in any column. Is this state
needed?

4.1 Events

   RemTime  A revoked key has been missing from the trust point DNSKEY
      RRSet for sufficient time to be removed from the trust set.

Again, Section 2.1 states that a revoked key is removed immediately &
permanently. There is no mention of any timer.

4.2 States

   Missing  ... [Discussion
      item: Should a missing key be considered revoked after some period
      of time?]

Wasn't this resolved? If so, the comment should be removed.

If it was resolved, as indicated in Mike's 7/27 response in the " 3
comments on timers-03" thread, by not having a missing key eventually be removed, then I don't see a way to ever purge a missing once it's been accepted. I suggest allowing this to be done manually by adding some wording somewhere (5. Trust Point Deletion?). Something like:

   If the resolver sees a validated DNSKEY RRSet that does not contain
   an existing trust point key, it MUST NOT discard they key. The key
   MAY be removed manually by the resolver operator [after 180 days?].

5.  Trust Point Deletion

   Alternately, a trust point which is subordinate to another configured
   trust point MAY be deleted by a resolver after 180 days where such
   trust point validly chains to a superior trust point.

First, I think the word 'Alternately' should have been removed when the
2 preceding paragraphs (in the 03 version) were moved to another
section. Second, I have trouble parsing this sentence. Does 'such trust
point' refer to the 'subordinate trust point' or 'another configured
trust point'?  Should 'a superior' be 'the superior'?

6. Scenarios - Informative

The scenarios in this sections are inconsistent with respect to how
much detail they specify about for new/revoked keys. For example, 6.1
is the only section that says to set the SEP an Zone key bits on a new
key. 6.6 is the only section that talks about sending updated DS
records to the parent zone.

I suggest inserting a new section before section 6.1:

  6.1 Zone Key Manipulations

  6.1.1 Creating a new Zone Key

  [text on creating a new key, setting bits, providing updated DS]

  6.1.2 Revoking a Zone Key

  [text on setting revoke bit, clearing SEP bit (see my comment on
   section 6.2 below, and providing updated DS]

Then each scenario could reference these sections. e.g. "Create a new
zone key as described in section 6.1.1."

6.2 Deleting a Trust Anchor

Shouldn't the SEP bit be cleared when a key is revoked? That way a
resolver/operator which doesn't implement timers and doesn't understand
the revoke bit shouldn't configure a known compromised key as a trust
point.

-- 
Robert Story
SPARTA

---

From: Mike StJohns <[email-masked]>
Date: Sat, 21 Oct 2006 21:34:55 -0400

At 04:09 PM 10/12/2006, Robert Story wrote:
>Sorry for the late review. I have read this draft, and I support it 
>going forward, but I think a few things need to be addressed before 
>sending it on.
>
>
>2.3.  Remove Hold-down
>
>I think this 'MAY' should be 'may' (or could) since it is talking 
>about the zone operator and not the resolver. Actually, the sentence 
>should probably be stricken entirely, and the next sentence reworded:
>

Yup - see the Sept 28th message in reply to [email-masked] on this thread.

>transition an 'AddPend' key to the 'Removed' state.

The start state is an amorphous state that can represent either keys 
not yet created or seen, or a key previously seen, but not currently 
active (e.g. removed from the  rrset prior to becoming valid).  It's 
just book-keeping.  Feel free to delete any information about the key.

>remove, the 'Removed' state has no data in any column. Is this state

A key in the Revoked state is "Revoked". All this says is that once 
the key is revoked,  you can and should delete your state information 
about the key after the removal time.  [I'm doing this without 
reference to a copy of the draft - I'm on vacation and decided to 
finish up the various replies at an Internet Cafe - I may be a little 
off target]

>permanently. There is no mention of any timer.

See above.  Removal Time is simply a timer for state table management 
and not for key acceptance.

>Wasn't this resolved? If so, the comment should be removed.

Yup.  One of the items from the Sept 28th note previously mentioned.

>comments on timers-03" thread, by not having a missing key 
>eventually be removed, then I don't see a way to ever purge a 
>missing once it's been accepted. I suggest allowing this to be done 
>manually by adding some wording somewhere (5. Trust Point 
>Deletion?). Something like:
>

Key can always be removed manually by the resolver - not a part of 
the protocol.  An existing trust point key is invalidated by a 
revocation or by the resolver removing it from the trust point set.

>trust point'?  Should 'a superior' be 'the superior'?

You're looking at a different version than I am - section 5 has two 
paragraphs and the "alternately" paragraph is the second paragraph - 
and it is an alternate approach to trust point deletion from the 
first paragraph.  The language in the -04 version is correct and 
non-ambiguous.  "a superior" is correct - consider "." and ".com" as 
superior to ".nominum.com".  "such trust point" refers to the trust 
point being considered for deletion.

>the revoke bit shouldn't configure a known compromised key as a trust

Too late to add the above  - should have been suggested for any of 
the prior versions  -and its a don't care for clearing the 6.2.

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