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

Warren Kumari <warren@kumari.net> Fri, 04 August 2017 14:12 UTC

Return-Path: <warren@kumari.net>
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 5DBD8131EAD for <dnsop@ietfa.amsl.com>; Fri, 4 Aug 2017 07:12:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 OoW8pabdruVx for <dnsop@ietfa.amsl.com>; Fri, 4 Aug 2017 07:12:23 -0700 (PDT)
Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9795131FED for <dnsop@ietf.org>; Fri, 4 Aug 2017 07:12:22 -0700 (PDT)
Received: by mail-ua0-x22b.google.com with SMTP id 80so7750375uas.0 for <dnsop@ietf.org>; Fri, 04 Aug 2017 07:12:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hGOXYzmSS8HCunWdbzdlcteS4m9sWdZ4UJbXgHFgl1g=; b=TnmqdOscYaDKaI3fE1LiQDni4vZNiJ+hSVoPs1AG/XIr4kkmwffa+JP7erGJW/8T3n /RLOtdMQ0moDMHj5nLzC+rpn0km5dfZgEdL5vmr1m8FNWl/RttrJv2PT9H7CCIyUldyj CoXrIxsGPYRA3i+I76aFClKqsYRAqgBWvNNEw0fgKzeBtLIOyQWZU+EBS7uG08aCKBSr lBgqDf7sFJiG086pejb0eyadCK42cJhbrv7cgOeHVN3aHppDZeWMT1F5l0Iufat5RD7h Ep/wC0GM0Jl7/39DRVN0lnIdAsWjc3YSfVHgXdQ/Fd8lloQsFAXsP+xZwzmfhxi37bxp hyaw==
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=hGOXYzmSS8HCunWdbzdlcteS4m9sWdZ4UJbXgHFgl1g=; b=YhHpFVxMHjWrIrghFXdcWS/0fgwVS7R964fRAeI5QBYLWTa7uHT0IQYEBnq1sQac3I FyCmAgKbdkmNF0uINnsgq5ZOqDDposYb8KdfjPP4n9Tl6Dd2Az/NPB013lP94mATWtD/ nkp+BT/hsm2hV1TldZxpYy/jynBEYqvmysXO8LmYnBsR3AfaZ0p1SwLQdzUq3dsQn/br byZcRc9X+Y8oOE5Li9mM2eG575fC2No3O5a9S+F9C2YZ5TuQ/LGzySEeh9dZw+US8SdT LenB1UXAlpFnLIZxAXPP5b2oqDtp6Xd+CSCDgNFpkMvLetXd0gUq7frsJ+FmaQV+yJHT Gvnw==
X-Gm-Message-State: AHYfb5jDYHsoWT9txKULrduFI6F/Q/BoO1eiWVb3l0TkNwz6JePeSB+0 m7K+Abbr2Iqp3RVLJaRxoTQkBEhO3MwK
X-Received: by 10.176.95.27 with SMTP id p27mr1564380uah.2.1501855941771; Fri, 04 Aug 2017 07:12:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.9.231 with HTTP; Fri, 4 Aug 2017 07:11:41 -0700 (PDT)
In-Reply-To: <CAMbs7kuOJEUzVEWLhmB17fMCTZ-Frw5EbHgPedFTb_7xHj8WmA@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>
From: Warren Kumari <warren@kumari.net>
Date: Fri, 4 Aug 2017 10:11:41 -0400
Message-ID: <CAHw9_i+YG3G5449etPLs5wfNpdHRzHgHJvZ4KM__NBexBwBEMA@mail.gmail.com>
To: Aanchal Malhotra <aanchal4@bu.edu>
Cc: Michael StJohns <msj@nthpermutation.com>, dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/FyfY64EO0rLAg0CTv-_TfyIF6fQ>
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:12:25 -0000

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.

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.

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

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