Re: [DNSOP] Emergency KSK Rollover for locally secure zones.
Aanchal Malhotra <aanchal4@bu.edu> Fri, 04 August 2017 14:44 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 4E9D01321AD for <dnsop@ietfa.amsl.com>; Fri, 4 Aug 2017 07:44:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] 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 Wm4uayFfWKBm for <dnsop@ietfa.amsl.com>; Fri, 4 Aug 2017 07:44:36 -0700 (PDT)
Received: from relay52.bu.edu (relay52.bu.edu [128.197.228.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24EB81321B0 for <dnsop@ietf.org>; Fri, 4 Aug 2017 07:44:35 -0700 (PDT)
X-Envelope-From: aanchal4@bu.edu
Received: from mail-oi0-f69.google.com (mail-oi0-f69.google.com [209.85.218.69]) by relay52.bu.edu (8.14.3/8.14.3) with ESMTP id v74EiKQt014152 for <dnsop@ietf.org>; Fri, 4 Aug 2017 10:44:20 -0400
Received: by mail-oi0-f69.google.com with SMTP id p62so1416463oih.12 for <dnsop@ietf.org>; Fri, 04 Aug 2017 07:44:20 -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=tm9ybzMz//bP29xzLuj/VcUdc5D8DsQ3gWwp9C35wio=; b=D6vKfFqKsPzt4J7PiqovZsm5Ty9tHs5qjBi0LUr4nlGmjarDt8U0d1rBkZH9kuivYU kpoZCu+/LnZuY5+W/G/Mfwysu0EaWpd6V3wFZ/oOS+vIHdq4tqEVPDQ1apwtv+Pqu4FY X2LBz/mWYUH+0/qj4QiBzTOfp4Ji7oeaITuQJJdH5fCLz7IfOfx/SluHdZO6OPcOAE4m cmDn39FVFHj/ies8m/T7fwfE6sOeak17CgznN4Qxe2T6UjIE7CZOt0SBTQnnixwRPOvQ TW6acHV15I0gZM6Q3y0STICxrDAFpIsm/n7nldXrafnuDQ54lEDPN7LA4YarmA+GWMnC l9wQ==
X-Gm-Message-State: AHYfb5hLqAFD2KybKEeAY65j3YgFZ72YZhQIwyORDJ4GAKCy2bzPcVCo kdzyqG+aMaaRCzm8V3usRJUV2g88HliyvEKgpKZvhKxxfUkqkzcMQroyQfkNh6UlIqJYmm/dgfq IXjNBVfMQ4Ylf7g==
X-Received: by 10.202.102.198 with SMTP id m67mr1746846oik.297.1501857860179; Fri, 04 Aug 2017 07:44:20 -0700 (PDT)
X-Received: by 10.202.102.198 with SMTP id m67mr1746835oik.297.1501857859921; Fri, 04 Aug 2017 07:44:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.121.75 with HTTP; Fri, 4 Aug 2017 07:43:59 -0700 (PDT)
In-Reply-To: <CAHw9_i+YG3G5449etPLs5wfNpdHRzHgHJvZ4KM__NBexBwBEMA@mail.gmail.com>
References: <CAMbs7ks-ZZ-tFpnNkgNx779ct0ns24d+pzKbzQhKuAxVnMUwrA@mail.gmail.com> <EE9ABA7D-BDB6-40FE-92B8-BC6335FF1898@nist.gov> <CAMbs7kuUMgXsvhG90zP=b+dL30oG0OQQwpGiBnE+e_FNXMvFgQ@mail.gmail.com> <70641a7b-8fe1-265a-5eb0-6e484ff7c735@nthpermutation.com> <CAMbs7ku=EoSK5AUULqBQ_T_7piBwhC-GVcacBb3-k01j-ZmVVQ@mail.gmail.com> <1214cb8a-54be-68d8-edda-9e1cd804996b@nthpermutation.com> <CAMbs7kuOJEUzVEWLhmB17fMCTZ-Frw5EbHgPedFTb_7xHj8WmA@mail.gmail.com> <CAHw9_i+YG3G5449etPLs5wfNpdHRzHgHJvZ4KM__NBexBwBEMA@mail.gmail.com>
From: Aanchal Malhotra <aanchal4@bu.edu>
Date: Fri, 04 Aug 2017 16:43:59 +0200
Message-ID: <CAMbs7kuRaGLQ8dOKK2QGuf9QPO6gvCmiddk_oXwJxQ8GDU9o8Q@mail.gmail.com>
To: Warren Kumari <warren@kumari.net>
Cc: dnsop <dnsop@ietf.org>, Michael StJohns <msj@nthpermutation.com>
Content-Type: multipart/alternative; boundary="001a1140a92c3e7e580555ee8851"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/dbtDKX3NAiOhSLPdYH61U7Vlan8>
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: Fri, 04 Aug 2017 14:44:39 -0000
Thanks Warren. On Fri, Aug 4, 2017 at 4:11 PM, Warren Kumari <warren@kumari.net> wrote: > On Thu, Aug 3, 2017 at 6:11 PM, Aanchal Malhotra <aanchal4@bu.edu> wrote: > > > > > > On Thu, Aug 3, 2017 at 11:49 PM, Michael StJohns <msj@nthpermutation.com > > > > wrote: > >> > >> I answered the question that you asked. > > > > > > Yes, thanks Mike. That answers my question about the attack. It was not > > clear that pre-published was synonymous with stand-by keys. > > > >> > >> Other people are weighing in on the root and stand by keys. > >> > >> Mike > > > > > > However, my question (not just for Mike.) > > > > "If we have a solution to this (subject of this thread) problem without > a > > back-up key set? And do we even care about it?" still remains. > > > > Well, we kinda do... > > The plan (which I haven't seen, but have been assured exists, is well > fleshed out and documented, etc) is that, if the primary is suspected > to be compromised (or lost), an "emergency key roll" will occur. > Wouldn't it be good if this document is accessible to all? Is there a reason for this document not being public? > > This involves, from what I've been told, publishing new keys / hashes > on the IANA site (https://www.iana.org/dnssec/files), and a > "significant press event", publishing the new key on newspapers, > blogs, etc. > > The attestations by the trusted community reps and signatures chaining > back to CA certs is supposed to prove the validity of this new key, > and the compromise of the old one. > That sounds like a plan (with a "significant press event" being my fav part :)) > > Unsurprisingly, it would be good if the emergency roll process never > needs to be invoked; the key protections are supposed to be safe > enough that this should be very unlikely. Much of this is very similar > to the loss / compromise of a CA root cert... > Yes I agree. It will be a highly unlikely and unfortunate event for the root trust anchor to be compromised. But what about emergency key rollover for other islands of trust/security, if there exist any? And do we care about them? > > W > > > Thx. > >> > >> > >> > >> > >> > >> On 8/3/2017 5:05 PM, Aanchal Malhotra wrote: > >> > >> Hi Mike, > >> > >> On Thu, Aug 3, 2017 at 10:47 PM, Michael StJohns < > msj@nthpermutation.com> > >> wrote: > >>> > >>> On 8/3/2017 3:01 PM, Aanchal Malhotra wrote: > >>> > >>> 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 Trust Anchor for the resolver? > >>> > >>> The resolver trust point trust anchor set contains both the old and > >>> pre-published stand-by key. When the old KSK is compromised, you set > the > >>> revoke bit on the old KSK, and sign the DNSKEY RRSet with both the > revoked > >>> KSK and the standby KSK. The stand by key does not trace its trust > through > >>> the old key except during the process of being added. The attempt to > >>> inject the new KSK is foiled by revoking the old KSK and publishing the > >>> revocation before the hold-down time expires for the resolver(s). > >> > >> > >> I understand and agree to what you say. And even RFC 5011 explicitly > >> states that this approach works only if there is a > >> backup/standby/pre-published (whatever name we like) and the assumption > that > >> both active and stand-by keys are not compromised at the same time. The > >> point is again, as Warren mentioned, that one needs two trust anchors in > >> this case. And the issues ensue.... Also, I am not sure if there is any > >> implementations that are actually doing standby-keys (not that I am > aware > >> of). > >> > >> What I am trying to say is that we do not have a solution to this > problem > >> without a back-up key set? > >>> > >>> > >>> At some point - ideally quickly after the old KSK revocation - you > >>> publish a new standby KSK long enough to inject it as a new trust > anchor. > >>> > >>> Mike > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > > > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
- Re: [DNSOP] Emergency KSK Rollover for locally se… Aanchal Malhotra
- Re: [DNSOP] Emergency KSK Rollover for locally se… Rose, Scott
- Re: [DNSOP] Emergency KSK Rollover for locally se… Wessels, Duane
- Re: [DNSOP] Emergency KSK Rollover for locally se… Aanchal Malhotra
- Re: [DNSOP] Emergency KSK Rollover for locally se… Warren Kumari
- Re: [DNSOP] Emergency KSK Rollover for locally se… Aanchal Malhotra
- Re: [DNSOP] Emergency KSK Rollover for locally se… Wessels, Duane
- Re: [DNSOP] Emergency KSK Rollover for locally se… Aanchal Malhotra
- Re: [DNSOP] Emergency KSK Rollover for locally se… Michael StJohns
- Re: [DNSOP] Emergency KSK Rollover for locally se… Aanchal Malhotra
- Re: [DNSOP] Emergency KSK Rollover for locally se… Michael StJohns
- Re: [DNSOP] Emergency KSK Rollover for locally se… Aanchal Malhotra
- Re: [DNSOP] Emergency KSK Rollover for locally se… Tony Finch
- Re: [DNSOP] Emergency KSK Rollover for locally se… Warren Kumari
- Re: [DNSOP] Emergency KSK Rollover for locally se… Aanchal Malhotra