Re: [DNSOP] RFC 6781 and double signature KSK rollover

Marc Groeneweg <Marc.Groeneweg@sidn.nl> Tue, 25 October 2016 12:08 UTC

Return-Path: <Marc.Groeneweg@sidn.nl>
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 938A912947C for <dnsop@ietfa.amsl.com>; Tue, 25 Oct 2016 05:08:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.522
X-Spam-Level:
X-Spam-Status: No, score=-4.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=sidn.nl
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 CcrIJl4xQQG5 for <dnsop@ietfa.amsl.com>; Tue, 25 Oct 2016 05:08:14 -0700 (PDT)
Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30DFB1293D9 for <dnsop@ietf.org>; Tue, 25 Oct 2016 05:08:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=from:to:subject:thread-topic:thread-index:date:message-id:references:in-reply-to:accept-language:content-language:x-ms-has-attach:x-ms-tnef-correlator:x-ms-exchange-transport-fromentityheader:x-originating-ip:content-type:content-transfer-encoding:mime-version; bh=EG2+jMbPfSOkq4fGQVhe2V9zWoPeHg0MFI0Xl5X7C9Q=; b=efuLL6ahF+pWuiNg8UANZkhClehEqT3brao44nT01RAH2xc2FKbx8+DyyBQBTxIG009lSoi0iLgDIo5ee/sb1z4HDi70PvPvEO3GtjIjmmcuGXX0Cam8W4jtU08CNvxKbrhewB7LsTgcpBeFkNpYqQ9rw4h1eqhpYO4gf10rf46qmKVrUgvUuqp5cmA+Yobjj72EAgo1vpGGTZ7od/IxuxU/ftAak7qehVEnAr+snZWc8hp4xPuB5c9Hq2LLtne7HPpBuqm+JOqpHf9Aok899sd4Yoh2IU/Ey8PRo/UCE/fUsYpPmHaVD+xPqlHLxWbyGW2Zvs5cUUr+LX/oAl2/mA==
Received: from ka-mbx02.SIDN.local ([192.168.2.178]) by arn2-kamx.sidn.nl with ESMTP id u9PC882e020927-u9PC882g020927 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL); Tue, 25 Oct 2016 14:08:08 +0200
Received: from ka-mbx01.SIDN.local (192.168.2.177) by ka-mbx02.SIDN.local (192.168.2.178) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Tue, 25 Oct 2016 14:08:08 +0200
Received: from ka-mbx01.SIDN.local ([fe80::e051:e184:7a9f:b09d]) by ka-mbx01.SIDN.local ([fe80::e051:e184:7a9f:b09d%13]) with mapi id 15.00.1130.005; Tue, 25 Oct 2016 14:08:07 +0200
From: Marc Groeneweg <Marc.Groeneweg@sidn.nl>
To: 'Matthijs Mekking' <matthijs@pletterpet.nl>, Marcos Sanz <sanz@denic.de>, "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [DNSOP] RFC 6781 and double signature KSK rollover
Thread-Index: AQHSLg39hYZ07wUGrUSldf77BA51ZaC42TmAgAA7L6A=
Date: Tue, 25 Oct 2016 12:08:07 +0000
Message-ID: <b49a76471a3f4972a9ddbe8049cce9c1@ka-mbx01.SIDN.local>
References: <OF5B3B3222.83E22422-ONC1258056.00536355-C1258056.0056B9D8@notes.denic.de> <d8285e11-9d99-227d-e0cd-0210abdf431a@pletterpet.nl>
In-Reply-To: <d8285e11-9d99-227d-e0cd-0210abdf431a@pletterpet.nl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.168.2.161]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/0E8sMHPVizHb5DtasYIbbFpHPQ4>
Subject: Re: [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: Tue, 25 Oct 2016 12:08:19 -0000

Hi Marcos,

For .nl we have rolled the KSK conform the double KSK method as described in RFC7583. We didn't notice a mistake or oblivion there :-0

Grtz,
Marc

-----Original Message-----
From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of Matthijs Mekking
Sent: dinsdag 25 oktober 2016 12:35
To: Marcos Sanz <sanz@denic.de>; dnsop@ietf.org
Subject: Re: [DNSOP] RFC 6781 and double signature KSK rollover

Hi Marco,

On 24-10-16 17:47, Marcos Sanz wrote:
> 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).

You are right: DS_K_2 may only be provided to the parent *after* the TTL of DNSKEY_K_1 has passed. RFC 7583 has more accurate timings for rollovers. The corresponding timeline is described in section 3.3.1.

Best regards,
   Matthijs


>
> 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
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop