IETF Logo Mail Archive

Re: [DNSOP] Emergency KSK Rollover for locally secure zones.

"Wessels, Duane" <dwessels@verisign.com> Thu, 03 August 2017 18:55 UTC

Return-Path: <dwessels@verisign.com>
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 F1415124B18 for <dnsop@ietfa.amsl.com>; Thu, 3 Aug 2017 11:55:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
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 cMfiXUt3eZQv for <dnsop@ietfa.amsl.com>; Thu, 3 Aug 2017 11:55:23 -0700 (PDT)
Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D7491200F3 for <dnsop@ietf.org>; Thu, 3 Aug 2017 11:55:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=2135; q=dns/txt; s=VRSN; t=1501786523; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=3VB8Jmt7RMVCV+mlYtOVyLmcd1nxhdtHKOq0CG0gxKg=; b=TZ3FTtbMJJTxQGQdCE9JMCwSI/rf9h/koBVe21XGjIVNRfsyUwwgNkMt PHaKQy/W+yqtgn4YnRVz6LBELk0SE7XlHD0kLTwyYVqcdijJXw1qPZjP2 cqDlJ8WXdNVt4afBfRy2QvhpXtbEQIHRlk47BsZlILiVj6J7SgVQ3hrey AlKYOyQYYPi2XaJ25bBDcKHhR0CQorw5EqDsBpx3jnJF+9TecbrNtotiR YqUcme1PxacFTTc9+gQQN9wsp4mP5a7hkR4AwyuxbINA5cRCNhluUBafs PrMopfjebUocd0XwrP8fWbPC9WG2kcnd+KKoRYx3zwMYXyd+uSKqTAV2p g==;
X-IronPort-AV: E=Sophos;i="5.41,317,1498521600"; d="scan'208";a="2076805"
IronPort-PHdr: 9a23:Qzn62xZEu/YAm9Yoy7ndMev/LSx+4OfEezUN459isYplN5qZrsiybnLW6fgltlLVR4KTs6sC0LuG9fi4EUU7or+5+EgYd5JNUxJXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6arXK99yMdFQviPgRpOOv1BpTSj8Oq3Oyu5pHfeQtFiT6+bL9oMBm6sRjau9ULj4dlNqs/0AbCrGFSe+RRy2NoJFaTkAj568yt4pNt8Dletuw4+cJYXqr0Y6o3TbpDDDQ7KG81/9HktQPCTQSU+HQRVHgdnwdSDAjE6BH6WYrxsjf/u+Fg1iSWIdH6QLYpUjm58axlVAHnhzsGNz4h8WHYlMpwjL5AoBm8oxBz2pPYbJ2JOPZ7eK7Sc8kaRW5cVchPUSJPDJ63Y48WA+cAOOpVqZT2qVkTohukHQSiBP3hxCJUhnH43qM63eYuEQDa0wIvEN0Dq2jUrMzwNKsOTey50LfEwDPeZP1Wwzf9743Ifwgvrf6MQ71watHRxlcrFwPellmbtILrPy6P2eQLrWeX4fdrWOWyhG8ptQ5xuSOvydkoionSnY8V1E7L9T94wIYuJN24R0h7bcS4H5tXsiGXLo17Sd4sTWFvvSY10LwGuZijcSgMyZQn3ALfZ+aIc4iP/BLvTOeRLilkhHJrYr6/gAyy8Uemx+bhVce0yE5HojdZntXWq3wA1RLe5tKaRvZ98EqtwyiD2g/c5+1cPEw4ibDXJ4Mjz7IsjJYfrEvOEyzslEnrj6KbcFgv9PKy5OT9eLrmo4eRN4pzig7jLKsjgte/AeEkMggWWGib5Pi82KXj/ULnRLVKieU7nbLDsJDcOMgboqG4AwpP3YYi7xa/CCqm0MgEkXUaNl5FZgyIj5LoO1HVIfD4AvG/j06wnzdswvDKJrzhApPTIXjfiLrtYKpx51RBxAcxw91T/Y9YB7EPLf7pREP8u9PVAgc8MwOuwubnDNt91pkZWWKKGqKWLa3TvkGT5uI0PeaMYJQVtS3jK/c7/f7ujGQ5mV4Sfamvx5cYdHe4HvF+L0WDfXXsmssBEXsNvgcmUePqjkaCUTlLZ3upXqIz+C07CIy8AYfEXICtj6SL3D2nEZ1OemBGFleMHG/yeIqeXfcDdCKSLdVlkjELTrWuUJIh2QuwuwDn1ro0ZtbTrwQRs5nj3dw9wuTXlRYu7zU8W82U1WqNRmUotmkVATI6wfYsj1Z6zwLJ7qVjmPFcDpgby+5AVApwfcrQ0OFhEN32QSrfc82IU1epRJOtBjRnHYF5+MMHf0soQ4bqtRvExSf/RuZNybE=
X-IPAS-Result: A2FvAADlcINZ//SZrQpcDg0BAQEDAQEBCQEBARYBAQEDAQEBCQEBAYQTgRQHjgiRdpYVDoFBOgkhDYUZAoR9GAEBAQEBAQEBAQEBAoEQgjMkAQ1GJgYBAQEBAQEmAQEBAQEBAQEBAQEBAQEBGgIeIBIBARgBAQEBAQEBAQE4NAsFCwIBCA0LHhAnCyUCBA4FG4oMGK9ki0EBAQEBAQEBAwEBAQEBAQEBAQEBHYMog0+BYiuCfIQ9NoNDgjEFn3cGAodRjmlZhH+KYZYBH4FDdxVJEgGEf4FJP3YBAYcGK4EFgQ8BAQE
Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id v73ItL9i004625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Aug 2017 14:55:21 -0400
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Thu, 3 Aug 2017 14:55:21 -0400
From: "Wessels, Duane" <dwessels@verisign.com>
To: Aanchal Malhotra <aanchal4@bu.edu>
CC: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [EXTERNAL] [DNSOP] Emergency KSK Rollover for locally secure zones.
Thread-Index: AQHTDIoOxZbUM6GsDU+V9YFHHp6NJg==
Date: Thu, 03 Aug 2017 18:55:20 +0000
Message-ID: <2EDD433D-BD40-4A54-BE52-57BC512C5988@verisign.com>
References: <CAMbs7ks-ZZ-tFpnNkgNx779ct0ns24d+pzKbzQhKuAxVnMUwrA@mail.gmail.com>
In-Reply-To: <CAMbs7ks-ZZ-tFpnNkgNx779ct0ns24d+pzKbzQhKuAxVnMUwrA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <EF5E7D15A62AA644B22ADEAFA6C03166@verisign.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/qlj4VcHvj0Fzqv27PfZaekdXI40>
Subject: Re: [DNSOP] Emergency KSK Rollover for locally secure zones.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 03 Aug 2017 18:55:25 -0000

Hello Aanchal,

I don't know if you consider this a solution, but you may want to take a look at RFC 8145, aka "Signaling Trust Anchor Knowledge."

Per this RFC, validators can convey trust anchor contents to zone operators via periodic queries.  By looking at the signal data you can see how many (and which) validators have old versus new keys.

It is implemented in recent versions of BIND and Unbound.

DW



> On Aug 3, 2017, at 8:50 AM, Aanchal Malhotra <aanchal4@bu.edu> wrote:
> 
> Dear all,
> 
> May be this has been discussed long ago on the list or elsewhere. Please guide me to proper pointers, if any.
> 
> Section 11.2.1 in [1] states the following for KSK rollover for locally secure zones:
> 
> "In rolling over the KSK, the secure zone may not know which resolvers have stored the public key as a trust anchor. If the network administrator has an out-of-band method of contacting resolver administrators that have stored the public key as a trust anchor (such as e-mail), the network administrator should send out appropriate warnings and set up a trusted means of disseminating the new trust anchor. Otherwise, the DNS administrator can do nothing except pre-publish the new KSK with ample time to give resolver administrators enough time to learn the new KSK."
> 
> I have the following questions:
> 
> a) This might work in case of an active KSK rollover. However in case of KSK compromise, which would require an emergency KSK rollover, what does the network administrator do in the 'Otherwise' situation from the above quote? 
> 
> b) I am just curious to know if this is even an issue or do network administrators care about it? And if it is, Is there any RFC or relevant doc or mailing list that discusses this problem/solutions, etc.?
> 
> References:
> [1] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-81-2.pdf
> 
> Thanks,
> Aanchal Malhotra.
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

v2.23.0 | Report a Bug | By Email