Subject: RE: on-offline keys : was RE: Delegation Signer Resource Record

From: "Loomis, Rip" <[email-masked]>
Date: Thu, 31 Oct 2002 13:26:16 -0500

Ed--
I think you just leapfrogged right over me with your train
of thought...let me try to catch up...

> Not having the ZSK on-line means that if the KEY RR is altered, it 
> can't be resigned and the chain of trust broken.  And in this case, 
> you might what a hard failure.

ITYM "...it can't be re-signed, and the chain of trust is therefore
  broken.  And in this case you might want a hard failure."

If my re-wording matches what you were trying to say:
Correct.  If the private portion of the ZSK pair is stored on-line
and is subsequently compromised, then the compromise recovery is
slightly faster if I don't need to change KSKs or DS records.  There
are some potential issues if I immediately generate a new ZSK and
remove the old one entirely without rollover, but compromise recovery
is *always* messy like that.  (I'm beginning to think that the TTL
on ZSKs and the SIG on ZSKs is going to be on the order of 5-10 minutes
max, in a perhaps futile attempt to force quicker cache coherency
following a ZSK compromise.  TTL for other records/SIGs could, and
probably should, be more like the typical 5-7 days of today.)

Note that I'm still _hoping_ that the [private portion of the] ZSK will
only be stored in an off-line signer--but dynamically-updated DNS
zones seem to be a fairly common and reasonable thing to plan for
when looking at zones outside the foundation/registry zones.
 
> As described below, the safety of a set of keys is a low as the least 
> safe key.  An on-line key means that off-line keys are just as weak. 
> However, what is being gained by this strategy is not having to go 
> back to the parent zone every time someone breaks into your name 
> server.

Not sure I grok your use of the common words weak/strong and safe/unsafe
in this context.  If both halves of the ZSK pair are online (the public
portion in the zone, and the private portion in the authoritative
master) then I'm not sure how that makes the offline-only KSK "weak".
Sure, if the ZSK is compromised then the attacker can modify the zone
and re-sign; that's why it's strongly preferred that the ZSK be kept
only off-line.  Unfortunately, I need to be able to re-sign a
dynamically-updated zone in real-time--not every zone, but some
zones.  I'm going to have to be willing to reduce the effective
security/assurance provided by the combination of the ZSK and KSK in
such a case; if I do so then I *really* need to minimize the window of
vulnerability following a compromise (since ZSK compromise would now
expected to be much more likely).

[...]
> Ultimately this bad idea went away when we discovered that if the 
> vulnerability that we feared was exploited, any gain from this 
> feature vanished.  E.g., if the server's host security was 
> compromised and the "weaker" off-line key was exposed, then the 
> attacker could forge SIG RR's with the weak key.  True, there's a SIG 
> RR with the stronger key (possibly) to compete with the SIG RR of the 
> (corrupt) weaker key, but a resolver will likely never see both in 
> time to compare them.
> 
> We gave up on trying to design for having different strength (in the 
> sense of how safe the private component is, not crypto-strength) keys 
> as a result of this observation.

I think in the DS world of separate ZSKs and KSKs, the issues are slightly
different.  What I'm trying to produce is a scenario where if a ZSK
is compromised then the parent zone does not necessarily need to take
any action to assist in the compromise recovery.  I think it's reasonable,
do-able, and (for the case of dynamic updates to signed zones) necessary--
and the existence of a separate KSK makes it possible.

I think we're actually more-or-less in violent agreement...

  --Rip

--
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: Edward Lewis <[email-masked]>
Date: Thu, 31 Oct 2002 11:03:06 -0800

>in this context.  If both halves of the ZSK pair are online (the public

I grok your nongrok.  I switched terminology on purpose.  By 
safe/unsafe, I mean:
     safe = private key is not vulnerable to a break in host security
     unsafe = private key is at risk of a break in host security
- in this context.

Safe/unsafe are terms I just applied in the last mail because (IMHO) 
they are more descriptive than strong/weak.  The terms strong/weak 
were the poorly chosen words used way back then, with strong=safe, 
and weak=unsafe.

>I think we're actually more-or-less in violent agreement...

Yes.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Derek Atkins <[email-masked]>
Date: 31 Oct 2002 13:55:46 -0500

> probably should, be more like the typical 5-7 days of today.)

If you have a SIG record with 5-7 day TTL and a KEY record with a 5-10
minute TTL, you run the risk of creating invalid signatures if you
remove the old KEY record too soon.  In particular, when you roll over
the ZKS, you MUST keep the OLD KEY around for another <MAX TTL> period
of time.

Granted, it is still safe to keep the KEY-RR TTL rather low, but that
doesn't mean you can _remove_ the key any faster than your
"outstanding" records.

But I think you knew that.. ;)

-derek
-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 31 Oct 2002 15:50:32 -0500 (EST)

> the ZKS, you MUST keep the OLD KEY around for another <MAX TTL> period

This also brings out another issue that we have seen in the workshops.
What TTL should be used in a cahce for verified data.
 a) the TTL the record arrived with
 b) the smallest TTL of
	any of the KEY and DS RRsets used to validate the RRset.

If the answer is b. then all data validated by a key in your  KEY RRset
will be expired within 10 minutes.

I do not know what the right answer is, a user selectable policy is
one possible answer.

Is this an issue that the DNSSEC-bis document should address ?

	Olafur

---

From: Paul Vixie <[email-masked]>
Date: Thu, 31 Oct 2002 22:49:45 +0000

> Is this an issue that the DNSSEC-bis document should address ?

if there's to be a policy, let it be at the authoritative side.  (the
signer can minimize ttl's at signing time if the ttl would otherwise
be longer than the signature.)  when caching/forwarding secure rrsets,
the standard dns ttl rules ought to apply.