[DNSOP] RFC 6781 and double signature KSK rollover

Marcos Sanz <sanz@denic.de> Mon, 24 October 2016 15:47 UTC

Return-Path: <sanz@denic.de>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE781298CA for <dnsop@ietfa.amsl.com>; Mon, 24 Oct 2016 08:47:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.631
X-Spam-Level:
X-Spam-Status: No, score=-4.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFr_IcsYIFlJ for <dnsop@ietfa.amsl.com>; Mon, 24 Oct 2016 08:47:28 -0700 (PDT)
Received: from office.denic.de (office.denic.de [81.91.160.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BF9F12965B for <dnsop@ietf.org>; Mon, 24 Oct 2016 08:47:28 -0700 (PDT)
Received: from office.denic.de (mailout-6.osl.denic.de [10.122.34.32]) by office.denic.de (Postfix) with ESMTP id 102411FB88 for <dnsop@ietf.org>; Mon, 24 Oct 2016 17:47:18 +0200 (CEST)
Received: from notes1.fra2.osl.denic.de (notes1.fra2.osl.denic.de [10.122.50.48]) by office.denic.de with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) id 1byhT4-0009CO-1E; Mon, 24 Oct 2016 17:47:18 +0200
To: "dnsop@ietf.org" <dnsop@ietf.org>
MIME-Version: 1.0
X-KeepSent: 5B3B3222:83E22422-C1258056:00536355; type=4; name=$KeepSent
X-Mailer: IBM Notes Release 9.0.1FP5 Octobe4, 2013
From: Marcos Sanz <sanz@denic.de>
Message-ID: <OF5B3B3222.83E22422-ONC1258056.00536355-C1258056.0056B9D8@notes.denic.de>
Date: Mon, 24 Oct 2016 17:47:16 +0200
X-MIMETrack: Serialize by Router on notes/Denic at 24.10.2016 17:47:17, Serialize complete at 24.10.2016 17:47:17
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/s2WrAbiZ42MEWVp16m86gcM_n9c>
Subject: [DNSOP] RFC 6781 and double signature KSK rollover
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Mon, 24 Oct 2016 15:47:30 -0000

Hi all,

my attention has been brought to the KSK rollover double-signature style 
described in 6781 and what I think is a mistake/oblivion there. Section 
4.1.2 states 

>  initial:  Initial version of the zone.  The parental DS points to
>      DNSKEY_K_1.  Before the rollover starts, the child will have to
>      verify what the TTL is of the DS RR that points to DNSKEY_K_1 --
>      it is needed during the rollover, and we refer to the value as
>      TTL_DS.
>
>   new DNSKEY:  During the "new DNSKEY" phase, the zone administrator
>      generates a second KSK, DNSKEY_K_2.  The key is provided to the
>      parent, and the child will have to wait until a new DS RR has been
>      generated that points to DNSKEY_K_2.  After that DS RR has been
>      published on all servers authoritative for the parent's zone, the
>      zone administrator has to wait at least TTL_DS to make sure that
>      the old DS RR has expired from caches.
>
>   DS change:  The parent replaces DS_K_1 with DS_K_2.

In that description it looks as if the only relevant TTL during the 
rollover is that of the old DS RR. In my eyes though, the replacement of 
the DS at the parent shouldn't happen before having waited at least the 
TTL of DNSKEY_K_1 itself. Otherwise validation errors might occur 
(mismatch between a cached DNSKEY_K_1 and the DS_K_2 at the parent).

I've seen TLDs doing their KSK rollover the way I describe (so it looks as 
it is standard operational practice), but the RFC doesn't reflect that. 
There are no errata filed for the RFC so far either.

Any thoughts on that?

Best,
Marcos