Subject: Re: Delegation Signer Resource Record

From: "Scott Rose" <[email-masked]>
Date: Thu, 31 Oct 2002 09:54:15 -0500

But try to word the suggestion as an administrative/operating suggestion and
not a protocol suggestion.

And repeat the suggestion in stronger terms in the mythic BCP on running a
signed zone/security aware server.  Whenever it shows up again :)

Scott
----- Original Message -----
From: "Loomis, Rip" <[email-masked]>

<snip>

>
> At the most, though, the DS protocol/standard document should recommend
> the use of two separate keys, rather than requiring it.  An
> operational BCP should probably discuss the issues like
> dynamic update of secure zones.
>
> --
> Rip Loomis                         Senior Systems Security Engineer
> SAIC Secure Business Solutions Group         www.saic.com/securebiz
> Center for Information Security Technology   www.cist-east.saic.com
>
> --
> 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/>

--
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 09:39:30 -0800

This might work in spite of some history below in a related area.

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.

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.

At 9:12 -0500 10/31/02, Loomis, Rip wrote:
...
>multiple keys as well--anyone who wants to do dynamic update
>of a signed zone will need to keep at least *some* of the
>keying material online.  Keeping only the ZSK on the
>authoritative master, and keeping the KSK on an off-line
>signing system, seems to be the best compromise right now
>to support re-signing a zone following dynamic update.

A long time ago, in a office vacated by a Labs, we once discussed the 
concept of key strength.  This was to be in the last four bits of the 
KEY RR flags field, the definition might appear in RFC 2065 (the one 
obsoleted by 2535).

We thought at the time that there would be a reason to keep some keys 
off-line and some on-line.  Key strength was a means to prevent 
on-line keys from replacing a SIG RR put in place by an off-line key.

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.

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