Subject: Draft Key Rollover History

From: Wouter Wijngaards <[email-masked]>
Date: Sat, 21 Apr 2007 10:48:05 +0200

Hi,

I have recently been thinking about key-priming for machines that have
been off-line long enough for their trust-anchors to go stale. I've
documented an idea in draft-wijngaards-dnsext-trust-history-00 (
http://www.ietf.org/internet-drafts/draft-wijngaards-dnsext-trust-history-00.txt
).

The properties of this solution are:
* The priming keys do not go stale, 10 year old software could install
and re-prime successfully.
* priming keys can be rolled themselves, reducing their exposure.
* priming keys can be revoked if compromised.
* withstand N-1 key compromises.

The zone owner is in control of choices
* Can be lots of keys, packets stay small.
* Number and size of keys can be chosen by zone operator.
  Say using 13 keys for the root zone.
* Number and size of keys can be changed by zone operator with a rollover.
* history is stored at a name of operators choice.
* (ancient) history can be served by a subdomain of the zone, so can be
offloaded to another authoritative server.
* all history data can be treated as unknown RR data types by caches.
* operators can move historical data around.
* operators can discard old private key data and still do all of the
above.

I would appreciate your review and comments.

Best regards,
   Wouter

--
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: Robert Story <[email-masked]>
Date: Mon, 23 Apr 2007 13:02:04 -0400

On Sat, 21 Apr 2007 10:48:05 +0200 Wouter wrote:
WW> I have recently been thinking about key-priming for machines that have
WW> been off-line long enough for their trust-anchors to go stale. [...]

WW> * operators can discard old private key data and still do all of the
WW> above.

I've only skimmed the draft, but my first though when I read this was:
what happens when an old key (which was never revoked) becomes
compromised? The scenarios in section 6 of timers is 'informative', so
a zone could roll keys without revoking the the keys as described in
6.3. So, does this present an attack on the stale update mechanism you
describe? If so, then operators might need old private keys to go back
and revoke the compromised key.

Another thought I had was with regards to delegating the historical
data to subzone. Why restrict it to a subzone? If you let it be any
name, operators could outsource maintenance of the historical data.

-- 
Robert Story
SPARTA

---

From: Wouter Wijngaards <[email-masked]>
Date: Tue, 24 Apr 2007 09:21:17 +0200

> and revoke the compromised key.

The operator can store a pre-self-signed key revocation (in a safe
place, it can only be used for denial of service really) before
discarding private key data. When the key becomes compromised, the zone
operator can insert the key revocation by rolling over the current keys.
This signs the key revocation with the current keys, and stores the key
revocation at the most recent history moment. Thus, old private keys are
not needed to revoke an old key.

> name, operators could outsource maintenance of the historical data.
Well, the reason I restricted it to a subzone is because I wanted the
current DNSKEY of the zone to sign a DS to it. Although this can be
relaxed, I think, and any name be used, or maybe a DS to the outsourced
name added or something. The DS would give an attacker more trouble
spoofing. This protection is really only a hurdle for the case where the
attacker has compromised N keys.

Best regards,
   Wouter