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

Aanchal Malhotra <aanchal4@bu.edu> Thu, 03 August 2017 22:12 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 3947912711E for <dnsop@ietfa.amsl.com>; Thu, 3 Aug 2017 15:12:25 -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 Xh3e5396Uxbt for <dnsop@ietfa.amsl.com>; Thu, 3 Aug 2017 15:12:23 -0700 (PDT)
Received: from relay60.bu.edu (relay60.bu.edu [128.197.228.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF127131C11 for <dnsop@ietf.org>; Thu, 3 Aug 2017 15:12:22 -0700 (PDT)
X-Envelope-From: aanchal4@bu.edu
Received: from mail-oi0-f70.google.com (mail-oi0-f70.google.com [209.85.218.70]) by relay60.bu.edu (8.14.3/8.14.3) with ESMTP id v73MBvam029638 for <dnsop@ietf.org>; Thu, 3 Aug 2017 18:11:57 -0400
Received: by mail-oi0-f70.google.com with SMTP id f11so24113oih.7 for <dnsop@ietf.org>; Thu, 03 Aug 2017 15:11:57 -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=StBB+LbcA3mrogR7DmI00wUFOakvo08HVHlBxbilQ6Q=; b=pSqMys/VagrlNokQFzn6yIUWRagP2p9qGV7odCObuk6GwkaqT1vCxpc2zBa+THGD8Y zjUIRnW+YXbVjKZF8oIJPvxwPNUDdBliUOe6ABJbpVScnINl8D21Hc1s6zM4+EakDV09 JpbQOZBczeBBCT3AWYH3CaT9sXTg/zZy1zrd2UTeCy0+wA2+KUtSmMaWeFVEUSvIhd6B 4enyPXyfmIUpMA8fP96iyh95EcQuxCBV/y7cKgHP2+oVIR9wp2OSUJN83rULBDSxjASJ NrveyWHa8Mmtya/kV8DZZXTGwYEATP6sTfyaSrEPQqQR28jIyAF6Y/GLO0eXVEeph7fL 6AgA==
X-Gm-Message-State: AHYfb5j66BHC+qouN31xSVJFqCasaXC+yJO/S1Noej4VYdH01Zcpa2IQ cHWJDsmKIBDRAxlmTQ6SIGRaiHYR2D1MjDQ//kh+M6qpmhO1l1eTV1WQz8j0tXucN/W6nnfCnEI jtGbDGsIeUooBZg==
X-Received: by 10.202.227.5 with SMTP id a5mr265532oih.240.1501798316674; Thu, 03 Aug 2017 15:11:56 -0700 (PDT)
X-Received: by 10.202.227.5 with SMTP id a5mr265525oih.240.1501798316364; Thu, 03 Aug 2017 15:11:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.121.75 with HTTP; Thu, 3 Aug 2017 15:11:35 -0700 (PDT)
In-Reply-To: <1214cb8a-54be-68d8-edda-9e1cd804996b@nthpermutation.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>
From: Aanchal Malhotra <aanchal4@bu.edu>
Date: Fri, 4 Aug 2017 00:11:35 +0200
Message-ID: <CAMbs7kuOJEUzVEWLhmB17fMCTZ-Frw5EbHgPedFTb_7xHj8WmA@mail.gmail.com>
To: Michael StJohns <msj@nthpermutation.com>
Cc: dnsop@ietf.org
Content-Type: multipart/alternative; boundary="001a1141a5722bfb1a0555e0ab9f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/lPheLcsAn8xM1l9cqMd5mc4gJe4>
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 22:12:25 -0000

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.

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 T*rust 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
>>
>>
>
>