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

Aanchal Malhotra <aanchal4@bu.edu> Thu, 03 August 2017 15:52 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 464EE1323A7 for <dnsop@ietfa.amsl.com>; Thu, 3 Aug 2017 08:52:03 -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 uaFUGHPdH23j for <dnsop@ietfa.amsl.com>; Thu, 3 Aug 2017 08:52:01 -0700 (PDT)
Received: from relay72.bu.edu (relay72.bu.edu [128.197.228.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86BD11320C5 for <dnsop@ietf.org>; Thu, 3 Aug 2017 08:52:01 -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 relay72.bu.edu (8.14.3/8.14.3) with ESMTP id v73FoVAp008145 for <dnsop@ietf.org>; Thu, 3 Aug 2017 11:50:32 -0400
Received: by mail-oi0-f72.google.com with SMTP id v68so1280295oia.14 for <dnsop@ietf.org>; Thu, 03 Aug 2017 08:50:32 -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:from:date:message-id:subject:to; bh=Lks11ybAR3UlusD/hC7HGvsllizF9itcwHuoBNMZldQ=; b=maD2FGodLqq7LaF2HZzKsBzTAttzHSlGVyD0bpj2GqGh2fCMUQb6PGMrYWGrtPSiUo Nwt6WXI0hS8M0GbUTI5uilbjSMb8y91JItJkZXKfJtxvmb0sZtgIeYwVYkKOS9obABjN WosYkTWO0Cbs732nnUvZXIp7qdUBuWC+OfuoWJRfw+wmqVjuPqB452j3FH3o4nZjCnEl honcZP+G8LSXoHQ3ld/OzmAJ8WU0fv/nLvX1GhWon3wcKjy9kaBTdmHDcDxqDqqChC+e ZmSRWyNF5gcwOeSclpjMxS3ACa9jInMXPoMqRx27IpG+jxzWwsAQWM+hnRAsviKJ7Z7L KqzA==
X-Gm-Message-State: AHYfb5i5XFaRiysfj4X6IeitS9QDkaJWIEeTrGI46OdHMeY8J3VIk1Uc xCvxPqnxTVVktlrsXfOffFNY40qrdu6kHAErO/umUMF5ePadyk01QMmtgLF9CinLql6uDJsYqpB Z4ATzF/sRkyyyGg==
X-Received: by 10.202.208.79 with SMTP id h76mr2092365oig.65.1501775431536; Thu, 03 Aug 2017 08:50:31 -0700 (PDT)
X-Received: by 10.202.208.79 with SMTP id h76mr2092353oig.65.1501775431291; Thu, 03 Aug 2017 08:50:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.152.129 with HTTP; Thu, 3 Aug 2017 08:50:10 -0700 (PDT)
From: Aanchal Malhotra <aanchal4@bu.edu>
Date: Thu, 3 Aug 2017 17:50:10 +0200
Message-ID: <CAMbs7ks-ZZ-tFpnNkgNx779ct0ns24d+pzKbzQhKuAxVnMUwrA@mail.gmail.com>
To: dnsop@ietf.org
Content-Type: multipart/alternative; boundary="001a113e40381d6db30555db570c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/NXaWYPWo6dGmXVktztfoxhWKBTU>
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 15:52:03 -0000

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.