Subject: comments on trustupdate-timers-04

From: Lindy Foster <[email-masked]>
Date: Thu, 12 Oct 2006 11:16:10 -0700

I have already sent purely editorial comments to MSJ.

I have a problem with Section 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.  If the resolver sees a validated DNSKEY RRSet without
   this key, it waits for the remove hold-down time and then, if the key
   hasn't reappeared, SHOULD discard any information about the key."

But the previous section (2.2) says:

"To mitigate, [blah blah blah] ...
   If the resolver ever sees the DNSKEY RRSet
   without the new key but validly signed, it stops the acceptance
   process and resets the acceptance timer.  If all of the keys which
   were originally used to validate this key are revoked prior to the
   timer expiring, the resolver stops the acceptance process and resets
   the timer."

So which is it? The resolver sees a new key, then gets an RRSet without
that key before the add-hold-down timer (acceptance time is reached).
You throw away all info about that key, or wait for another timer
(remove hold-down) to expire? I think it is the former. I think the
Remove Hold-Down timer is really supposed to be talking about keys
being REVOKED, not about new keys subsequently not appearing in
RRSets. Or is it something else altogether?

Other than this clarification, I support this draft being
advanced. FYI, I am currently working on an implementation
of this draft.

- --
Lindy Foster
SPARTA, Inc.
[email-masked]

--
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: Mike StJohns <[email-masked]>
Date: Sat, 21 Oct 2006 21:18:52 -0400

At 02:16 PM 10/12/2006, Lindy Foster wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>

See the note I sent to [email-masked] dated 28 Sept - subject 
Re: WGLC on trustudpate-timers.  This point was explicitly discussed.

Both are correct.

The MAY in section 2.3 needs to be lower cased as its guidance for 
the content on the zone rather than actionable protocol elements.

Information about a key (e.g. key state) is not the key itself.  If 
the resolver sees and RRSet without the key, it MAY delete the 
information about the key, but it really SHOULD just mark the key as 
absent and wait a while  (remove hold down) before it deletes all 
state on the key.  It's implementation hints.  Practical effect for 
the resolver is the same in either case, but knowing what keys have 
been offered and then withdrawn may be useful for debugging what's 
going on - but that has no affect on the key acceptance policy.

My comment in the referenced message was that I was going to leave it 
as it was, but may end up deleting the section 2.3 paragraph at a 
later point after implementatin experience.

>- --
>Lindy Foster
>SPARTA, Inc.
>[email-masked]
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.5 (GNU/Linux)
>Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
>iD8DBQFFLoZqAxJowVHHlGYRAv7MAJ9dYFFB9vguFhGwtiPD2irY6j2sQQCfaUZr
>QPt9S29VUWJx2pImeyPw9vI=
>=NXqr
>-----END PGP SIGNATURE-----
>
>--