Re: [DNSOP] rfc4641bis: ZSK-roll-frequency

Paul Wouters <paul@xelerance.com> Thu, 21 January 2010 18:03 UTC

Return-Path: <paul@xelerance.com>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E60D73A684E for <dnsop@core3.amsl.com>; Thu, 21 Jan 2010 10:03:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x616TvXUfolS for <dnsop@core3.amsl.com>; Thu, 21 Jan 2010 10:03:50 -0800 (PST)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 1EA583A6837 for <dnsop@ietf.org>; Thu, 21 Jan 2010 10:03:50 -0800 (PST)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) by newtla.xelerance.com (Postfix) with ESMTP id DDDED571B4; Thu, 21 Jan 2010 13:03:45 -0500 (EST)
Date: Thu, 21 Jan 2010 13:03:45 -0500
From: Paul Wouters <paul@xelerance.com>
To: Edward Lewis <Ed.Lewis@neustar.biz>
In-Reply-To: <a06240800c77e1b276941@[192.168.1.106]>
Message-ID: <alpine.LFD.1.10.1001211259410.12114@newtla.xelerance.com>
References: <C77DCA5E.A431%scott.rose@nist.gov> <a06240800c77e1b276941@[192.168.1.106]>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Cc: dnsop WG <dnsop@ietf.org>
Subject: Re: [DNSOP] rfc4641bis: ZSK-roll-frequency
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jan 2010 18:03:51 -0000

On Thu, 21 Jan 2010, Edward Lewis wrote:

> If I were to fit this into the text below...
>
> #<t>
> #        The motivation for having the KSK's effectivity period
> #        longer than the ZSK's effectivity period is rooted in the
> #        operational consideration that a change in the KSK involves
> #        interaction with an external entity, usually the parent zone
> #        or possibly a trust anchor repository, and this interaction
> #        is anticipated to have significant latency (including the
> #        need to verify the other party has made the necessary change.
> #</t>

Maybe make it more explicit that an intra-organisation key change can
and probably should happen frequently, where-as an inter-organisational
key change, because it involves other organisations, is more difficult
and should be kept to a minimum?

Again, think of a zone administrator who had access to a private ZSK
leaving your organisation. It would be a good security policy to rollover
the ZSK as part of the procedure of revoking this person's access to
the organisation. And a good reason to have an HSM so you do not need
to do the same with the KSK.

Paul