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

---

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

---

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.

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

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

>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

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.

---

From: Thierry Moreau <[email-masked]>
Date: Mon, 31 Jul 2006 23:00:25 -0400

Eric Rescorla wrote:

> [... explanations on security model for draft-ietf-dnsext-trustupdate-timers ...]
> 

A "threat model" is something seldom discussed in DNSEXT WG /
namedroppers (now that this draft is looked at by a broader audience, it
may become relevant, hinted by your post). A while ago, I thought threat
model explicitness (e.g. in the form of "catastrophic failure mode"
disclosure) would easily be included in the TAK requirements draft
document produced by the wg, but it was not the case.

Accordingly, by default, the wg position would be that threat model
discussion is not a required step for selecting an automated TAK
rollover solution. Personally I disagree, but that seems to me close to
a wg consensus.

Regards,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]