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

Aanchal Malhotra <aanchal4@bu.edu> Thu, 03 August 2017 19:02 UTC

Return-Path: <aanchal4@bu.edu>
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 32325127B73 for <dnsop@ietfa.amsl.com>; Thu, 3 Aug 2017 12:02:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 sBJN1xI3R1z1 for <dnsop@ietfa.amsl.com>; Thu, 3 Aug 2017 12:02:47 -0700 (PDT)
Received: from relay55.bu.edu (relay55.bu.edu [128.197.228.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE3671270AC for <dnsop@ietf.org>; Thu, 3 Aug 2017 12:02:46 -0700 (PDT)
X-Envelope-From: aanchal4@bu.edu
Received: from mail-oi0-f72.google.com (mail-oi0-f72.google.com [209.85.218.72]) by relay55.bu.edu (8.14.3/8.14.3) with ESMTP id v73J2EA2032556 for <dnsop@ietf.org>; Thu, 3 Aug 2017 15:02:14 -0400
Received: by mail-oi0-f72.google.com with SMTP id g131so1611254oic.10 for <dnsop@ietf.org>; Thu, 03 Aug 2017 12:02:14 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G62TliZLE8GswJ8Yp81lOqxImj2DkuyIbzImDfLCTaA=; b=sVHYapV9txlM9oK5nCGG+2U1mc28V8rogsLamIZh5Fy0vJ1u4U3LdYU5YLiCB89ur5 hBbYF4pU7KQ6p0LoZPb+RKC64VFMHGzg+JlSUsFNy8S7JSbyRRcWT7IeMoqvPqvms0Rp /nhqHvLfb5MGgWfo+JG+E2HXWVfadLxLp9ZVjiNCMbzLQDzmIHzM7JDAnCg6FRzdBWh+ qUMV143IdyZ/MOYQDiA3RXbQwJDB/mujRbwKqqyRGqjYcsWrz5fb1g68o4ZlszghERY0 vkrm5iMsYt6aOeoFl/nZWoJrtSiDjZY0lcyfA5dtJtECe0RjLB1dHi/UqBLiQB74SM5Z fldA==
X-Gm-Message-State: AHYfb5g4b9fZ2FlU72NZqn3k3+XE+Fcokm83NVWbJ1f9ld0KPQoXK0y/ qguWtShc2FgDmGyyEWMks815p9YsVatboBd+pzaaQUk5jqvM3HQwyzEHlHOu375UUFXUwXAVPuM grFSPjbWDS4YwoA==
X-Received: by 10.202.208.79 with SMTP id h76mr2621137oig.65.1501786934055; Thu, 03 Aug 2017 12:02:14 -0700 (PDT)
X-Received: by 10.202.208.79 with SMTP id h76mr2621122oig.65.1501786933688; Thu, 03 Aug 2017 12:02:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.121.75 with HTTP; Thu, 3 Aug 2017 12:01:52 -0700 (PDT)
In-Reply-To: <EE9ABA7D-BDB6-40FE-92B8-BC6335FF1898@nist.gov>
References: <CAMbs7ks-ZZ-tFpnNkgNx779ct0ns24d+pzKbzQhKuAxVnMUwrA@mail.gmail.com> <EE9ABA7D-BDB6-40FE-92B8-BC6335FF1898@nist.gov>
From: Aanchal Malhotra <aanchal4@bu.edu>
Date: Thu, 3 Aug 2017 21:01:52 +0200
Message-ID: <CAMbs7kuUMgXsvhG90zP=b+dL30oG0OQQwpGiBnE+e_FNXMvFgQ@mail.gmail.com>
To: "Rose, Scott" <scott.rose@nist.gov>
Cc: dnsop@ietf.org
Content-Type: multipart/alternative; boundary="001a113e4038b6133a0555de04ac"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/8VCFd3AnFF2ntO1ROJyhqvxLG2k>
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 19:02:49 -0000

Hi Scott,

Thanks for the response. I have another question in that case. Please see
below.


On Thu, Aug 3, 2017 at 6:17 PM, Rose, Scott <scott.rose@nist.gov> wrote:

> Hi,
>
> (800-81 author here)
>
> That needs to be updated as it was from the earlier revision of 800-81. It
> really should stress the use of RFC 5011 automated trust anchor update
> process. The first version of the doc assumed RFC 5011 was not available in
> the majority of implementations, which is not the case now. I’d probably
> update that to recommend (and stress) to always use the RFC 5011 rollover
> process.
>
> As for emergency rollovers, some admins do worry about it and plan for it
> by having a pre-published KSK in the DNSKEY RRset at all times (not just
> during an actual rollover process). RFC 5011 can be used there too (see the
> “Scenarios” section in RFC 5011).
>
A DNSKEY RRset with pre-published KSK is signed by the old (now
compromised) KSK. When the resolver uses RFC 5011 for the trust anchor
update, the attacker can inject a new KSK (signed by the compromised KSK).
Which KSK is now the new T*rust Anchor  *for the resolver?


> There isn’t a single doc that focuses on KSK rollovers, but it is
> discussed in the BCP docs like RFC 6781 and other implementation-specific
> documents.
>
> Scott
>
> On 3 Aug 2017, at 11:50, Aanchal Malhotra 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]
> <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-81-2.pdf>
> 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
>
> ===================================
> Scott Rose
> NIST ITL
> scott.rose@nist.gov
> +1-301-975-8439 <%28301%29%20975-8439>
> GV: +1-571-249-3671 <%28571%29%20249-3671>
> ===================================
>