Subject: Comments on dr

From: Eric Rescorla <[email-masked]>
Date: Mon, 31 Jul 2006 10:34:12 -0700

This draft uses a variant of the two-key strategy: a given island can
have an arbitrary number of keys. The draft (S 5) suggests having two
keys, an "active" key and a "stand-by" key, but this isn't wired into
the protocol. This differs from the two-tier model discussed above in
two respects:

1. From the perspective of the relying party, all keys have
   the same security level. Any key can be used to sign a
   new key, allowing automatic rollover in non-compromise
   cases. However, keys cannot revoke other keys--to revoke 
   a key you produce a self-signed revocation. 
2. When you roll-over, you make the previous stand-by key
   the active key. 

The advantage of this scheme is that it can survive compromise of
either key. The disadvantage is that it encourages having two keys
with roughly similar security levels, thus making compromise of the
stand-by key more likely. In particular, if you intend for the
stand-by key to become the active key, then even if you initially
store it in a high security module, you need some mechanism for
releasing it which represents a potential attack vector. If you simply
always treat the standby key as a key-signing-key then this problem
goes away and while this is permitted by this draft, it seems like
this would be good guidance.

A second issue is that because you need access to any given key in
order to revoke it, you are more vulnerable to attacks where the
active key private key is destroyed (e.g., an attacker steals it and
then erases the disk) and this is a higher risk because the active key
is used frequently. You would not be able to revoke the key in such
cases. I don't know if it's possible to produce a pre-signed
revocation as discussed in [1], but it would presumably be advisable
in this instance. Note that you can always remove it from the
RRSET but this doesn't provide an authenticated removal, right?
Also, what do you do if you lose all your keys...?

So, in general, I think it's a mistake to have a system where you
assume that both keys are about equally likely to be
compromised. Certainly, if you're worried about a computational attack
and the keys are the same length, then any sane attacker will break
all the keys before tipping his hand (this is a constant factor). And
once you have asymmetric lengths, then it's unattractive to use them
identically. If this is the direction the WG wants to go in,
I think it would be appropriate to discuss what threat model
motivates it.

-Ekr

[1] Note that it's possible to design a system like this where
the high-assurance key can be revoked but not reprovisioned
automatically. For instance, you pre-sign a self-revocation
for the high-assurance key which you then release in the
case of compromise. There's also Micali's trick of having
the high-assurance cert contain a digest of some secret random
value X (i.e., H(X).. To revoke the key you release X and
everyone can verify X.							

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