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

Aanchal Malhotra <aanchal4@bu.edu> Thu, 03 August 2017 19:59 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 6F53C131891 for <dnsop@ietfa.amsl.com>; Thu, 3 Aug 2017 12:59:00 -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 DDiwAxOP_kKk for <dnsop@ietfa.amsl.com>; Thu, 3 Aug 2017 12:58:58 -0700 (PDT)
Received: from relay77.bu.edu (relay77.bu.edu [128.197.228.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C554131C2D for <dnsop@ietf.org>; Thu, 3 Aug 2017 12:58:56 -0700 (PDT)
X-Envelope-From: aanchal4@bu.edu
Received: from mail-oi0-f71.google.com (mail-oi0-f71.google.com [209.85.218.71]) by relay77.bu.edu (8.14.3/8.14.3) with ESMTP id v73JwPQR024307 for <dnsop@ietf.org>; Thu, 3 Aug 2017 15:58:26 -0400
Received: by mail-oi0-f71.google.com with SMTP id x3so1708835oia.8 for <dnsop@ietf.org>; Thu, 03 Aug 2017 12:58:26 -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=p3XlyuTPKJy39M3HsaJzCfmE5z8fKtO4skWPSL21U2M=; b=miBQUTsmS1a/f4aSvgn2MPxdoVnuxAAQFKSbtFGo+svzOf9SoGXtGjTkY/QE02diWC zenFoYh2me+9bNVXF58Es1r87ZLyJiCidwoEY/gPsAJEfq+A6d7aYi/8X/qEsrYCjDkM LWgtfiUnNqz33wVcmBRr3COKU9/e2Bb5f4zsFmMulFZ6e/MJX6W+gZJdeBEAP2sFeFOa 9KHyI+VVCnthxKHontYnAyO+GbXJO6V7lPTnPLs/ZTFlS3XCjACkgofKmUg8jr9Dv9rz kvOW52wAPzGyI3zLqz6SMjmjPzqXN+8T6drKlJabyh3dvWSJEztIwn5GgBqs7k7gEyAE FE+g==
X-Gm-Message-State: AHYfb5j4CmDAguFhqCvoKnJ3usxfuIxLU3yoLu7RWO8StD5R6ovf5aw6 X8Ool5+rjFLV7RVrJEixLPM3wj9Rq0GzBHd5g8Iddc+2g3eQVqLwnzMy5d1O7oVwvF3kwxo28rW 3QtIcGUY9h41qqw==
X-Received: by 10.202.166.196 with SMTP id t65mr2994293oij.63.1501790305372; Thu, 03 Aug 2017 12:58:25 -0700 (PDT)
X-Received: by 10.202.166.196 with SMTP id t65mr2994278oij.63.1501790305095; Thu, 03 Aug 2017 12:58:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.121.75 with HTTP; Thu, 3 Aug 2017 12:58:04 -0700 (PDT)
In-Reply-To: <2EDD433D-BD40-4A54-BE52-57BC512C5988@verisign.com>
References: <CAMbs7ks-ZZ-tFpnNkgNx779ct0ns24d+pzKbzQhKuAxVnMUwrA@mail.gmail.com> <2EDD433D-BD40-4A54-BE52-57BC512C5988@verisign.com>
From: Aanchal Malhotra <aanchal4@bu.edu>
Date: Thu, 3 Aug 2017 21:58:04 +0200
Message-ID: <CAMbs7kv63z8K29Hqa4vC=p8DOtiJr96js4jQUx9k7eJ2HopSfg@mail.gmail.com>
To: "Wessels, Duane" <dwessels@verisign.com>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="001a113e7cf2a9aaf30555decd28"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/lf3X5LFqxUYHWsvXePvv0ZgB2cs>
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:59:00 -0000

Hi Duane,

Thanks for pointing to RFC 8145. It's a very nice mechanism to allow zone
administrators to know the status of key rollover in the DNSSEC signed zone
to take further decisions.

However, I still don't see how it would help in case of trust anchor/KSK
compromise. With RFC 8145, the zone administrator would know that the
resolvers are using old (now compromised) trust anchor/KSK for validating
the data. But there is no way for them to roll-over this trust anchor/KSK
in an authentic way. In other words, this RFC might help in detecting the
problem (when a resolver signals a key that is not the zone's trust
anchor). But I don't see anything in the RFC that says what a zone
administrator can do in such a case. Am I missing something?

Thx,
Aanchal Malhotra.


On Thu, Aug 3, 2017 at 8:55 PM, Wessels, Duane <dwessels@verisign.com>
wrote:

> 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
>
>