Subject: KEY RR Key Signing (KS) Flag

From: Edward Lewis <[email-masked]>
Date: Fri, 25 Oct 2002 10:37:12 -0400

In the draft there is mention of requiring the parent to maintain a 
history of KEY RR's used by children to generate DS RR's.  This is 
done to guard against successful replay attacks that might reset the 
DS RR set to an older version.

Requiring the parent to maintain a history will likely lead to an 
unstable situation.  How long a history may need to exist is hard to 
determine, and the storage needed for this is somewhat linear to the 
length of time in the history.  (Actually, sublinear initially as the 
number of signed children will grow - considering that today, the 
number of DS'd children is roughly 0.00.)

I would suggest that moving the discussion of automating rollover be 
removed from this draft anyway, so I won't comment further on this. 
(Just because the KS "enables" this doesn't mean it is responsible 
for proper rollover technique.)

The rest are all editorial comments.

Throughout the doc:

The terms "key-signing key" and "zone-signing key" should be 
hyphenated.  This is from a local "Mr. Language Person."

Section 1:

"Key Signing Key flag" -> Key-Signing Key (KSK) flag

Section 2:

"The bit 15th bit" -> lose the first bit.

Section 4:

"Using the flag a key rollover can be automated." -> The flag enables 
key rollover to be automated.

Also, note that "if the bit is changed, the cryptographic key data in 
the RDATA assumes a new DNS indentity because the bit is used in 
calculating the footprint."

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

--
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: Jakob Schlyter <[email-masked]>
Date: Fri, 25 Oct 2002 20:37:08 +0200 (CEST)

On Fri, 25 Oct 2002, Edward Lewis wrote:

> One is to regenerate the DS RR.  I'd stipulate that this isn't
> necessary - you can re-sign the previously produced DS RR with the
> new key.  If the registry maintains and backups of the current DS
> RR's, there is no need to have the KEY RR's hang around.

the registry might want to keep the KEYs in the unlikely event someone
decides we should change the digest algorithm.

	jakob

---

From: Edward Lewis <[email-masked]>
Date: Fri, 25 Oct 2002 14:58:46 -0400

>decides we should change the digest algorithm.

In that case, the DS draft should make such a suggestion.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer