Subject: Re: Comments on dr

From: Eric Rescorla <[email-masked]>
Date: Mon, 31 Jul 2006 11:19:08 -0700

The subject here should refer to:

draft-ietf-dnsext-trustupdate-timers

I read -02 but on quick skim -03 looks architecturally pretty
similar.

-Ekr

--
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: Mon, 31 Jul 2006 21:09:08 -0400

Hi Eric -

Thanks for the analysis.  It agrees with what I assumed when doing 
the design.  As far as I can tell, none of these comments indicate a 
weakness in the protocol, but discuss more the handling of the keying 
material and its security?  If that's the case, it may make sense 
(once this document passes) to get DNSOPs to write a document on the 
general topic of operational security of DNSSEC key material.

At 01:34 PM 7/31/2006, Eric Rescorla wrote:
>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.

Agreed, but probably not a protocol issue?  So maybe more appropriate 
as a DNSOP document...

I considered the "master key" approach, but it actually has more 
vulnerabilities and has this interesting requirement that each trust 
point MUST have more than one key.  As written, a trust point can 
start out with one key (trust anchor) and add more as necessary or 
desired.  That means you can deploy the new software (which 
implements the protocol) and eventually add new keys to existing 
trust points without having to re-issue the trust point key set.

>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...?

Start over.  The protocol isn't designed to completely deal with 
operator stupidity.  I'm not sure I've seen any IETF protocol that 
does a good job of DWIM (Do What I Mean).

And it isn't easily possible to do a pre-signed revocation - the 
RRSIG is over the atomic set of DNSKEYs at the name.  The timing 
doesn't matter, but the set of keys signed at any given time is going 
to vary - especially if you're creating a new key to deal with the 
compromised key.

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

I'm pretty sure this is an operational assessment rather than a 
protocol assessment.  The protocol doesn't assume ANY values for 
"probability of compromise" for any key material.  The key material 
owner can take any precautions from keeping a copy of the private key 
escrowed (using threshold, a safe deposit box, multiple flash drives, 
cryptographic tokens) to writing it down on a card in his/her 
wallet/purse, to leaving it in his desk, to publishing it on the 
internet.  Each of these has its own characteristics (e.g. safe 
deposit box may be harder to steal the private key but single copy 
may end up with higher probability of losing it, but publishing it on 
the internet has the exact reverse - easier to steal the key, but 
harder to lose it).  I think its reasonable to leave the operational 
security assessments and key protection mechanisms to the zone owner.  Comment?

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

The computational attack is no better or worse than any other part of 
the rest of DNSSEC - if we're worried about this in general for 
DNSSEC, we should talk about it in that context, rather than imputing 
it as a sole issue for trust anchor roll over.

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