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: Olaf Kolkman <[email-masked]>
Date: Fri, 25 Oct 2002 18:51:06 +0200

Thanks for your comments, one question back though

 Edward Lewis <[email-masked]> writes:
 * 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.)

I see what you mean... but..

In the security section I've added the reference to the 'old key' to
avoid people making mistakes, i.e. to document an attack vector on
(mis)use of the keyflag. I think that sort of information belongs in
the security section.

Maintaining history is a way to cope with that attack vector. Note
that you only have to maintain history of the key most recently used
(the key which was in the keyset to authenticate the new key with). I
refer to that key as the key used 'previously', maybe there is a
better word that does not refer to all keys that where used in the
past, suggestions from "Mr Language Person" are welcome :-).

 * The rest are all editorial comments.

Thanks...

--Olaf

---

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

>I see what you mean... but..

There's that word "but" again...

>past, suggestions from "Mr Language Person" are welcome :-).

There are three ways in which a registry may use a copy of a KEY RR 
(that has been used to make a DS RR).

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.

Two is to validate the submission of a new KEY RR set for DS 
RR-ization.  Whether this is necessary is dependent on registry 
policy - if the update requests are authenticated via a non-DNS 
method, the KEY RR is needed, what is needed is (most likely) the 
certificate holding the public key of the registrant (or registar to 
be more general).

Three is to detect any "looping" through the keys.  This implies a 
history of more than one KEY RR generation, which is something you'd 
want to avoid having in a distributed system.  It is also conceivable 
that the registrant meant to reuse an old key (as part of some bad 
advice from their security team or going back to an uncompromised 
key).

For the third case, I'd place the impetus on the client to make sure 
the parent has the right DS RR set for the client.  If we can 
maintain that all flows initiate from the child upwards instead of 
having the parent initiating anything, the system will be more 
modular and scaleable.

I.e., the child notifies the parent that there is a new keyset, 
parent gets it.  The child verifies that the parent has processed the 
keyset and (perhaps) alters the keyset and notifies the parent again. 
So, if there's a problem, the child notices by verifying what the 
parent has, senses an error and notifies the parent.  That's the 
paradigm I think will be the most stable, even if it seems that the 
parent isn't doing much hand holding.

---

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

> 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