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

Michael StJohns <msj@nthpermutation.com> Thu, 03 August 2017 21:49 UTC

Return-Path: <msj@nthpermutation.com>
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 ACB8F12EB2B for <dnsop@ietfa.amsl.com>; Thu, 3 Aug 2017 14:49:41 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.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 tLrKYRlh6h6c for <dnsop@ietfa.amsl.com>; Thu, 3 Aug 2017 14:49:40 -0700 (PDT)
Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 D4E71131950 for <dnsop@ietf.org>; Thu, 3 Aug 2017 14:49:39 -0700 (PDT)
Received: by mail-qt0-x232.google.com with SMTP id 16so15545179qtz.4 for <dnsop@ietf.org>; Thu, 03 Aug 2017 14:49:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=EPqvczlDVrhD3qPVyvBpzUeEhy3jmiJQWund1YdNs/E=; b=IWIZWDEYHT76K7tD7XG2cCDT+im78srFmEEI/Cl+1QvI/rijyyKm3p2ursRBMA34/a 6VJy9aXFUOBZDD6X+riJRRK4/ReAKXvQyDvcKgWrQ0r39monSG5BVmOR3Cimlx+P61iB VqbS2v6eeUwFHv60uC8b5z+gn4LUg8CXPjo9ZnYwDN2xoPmyhZl+VTLO7j+1lwOrxrXO UYD7UZRmEzx0OHM/GBIuRFRKQxFbhJDmjQPC7a5raDejVO79vOlFYEa4zdv3JG+5StSV ObztP0eGN7tt/4vAzl1qLypeu4+iEMfRiUG6xjiOFl+Cvv6j9KV5ig68/scOX9sc49mC 0yMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=EPqvczlDVrhD3qPVyvBpzUeEhy3jmiJQWund1YdNs/E=; b=X/ECRh+zCy4AWUULoVuvoXNjKyEfIzTSwAB5Fi7Yv4Ktn4KHmeXVL0a0Pvy0e+NXf7 wPcLNS1gEMaKYXGrWUBDcapi9YJ45o/JjjAruPLqQiatM/g0QDqzlXGdt8svTlK3aeOa 5Arf+6OKkWoMC9dDDFhpU42/mDNNyFOdUKLz4qpPBn9KQZX0gzoRiA+J8UhDSdpN0BFO yEz+y44Ol3o5fSHUpxfmxJVYmb1fqCnwRrb0Wy4zl/MytPnU5Ubhlhq5VK0lechzQpDb 30MoGJXVS9Gl9A9iepwJErqP/yv1n+JyfEmr7QUUqgMN0RfxSdcHjEZT4QBy7c5sIAxj mZPg==
X-Gm-Message-State: AHYfb5i7VCZQSDpZ/2Mw2Nr6B6N07G5Zd/r9vaz3CbCzLZ8KXTq1UDC0 jBjRg4reY0xYH53e5GA=
X-Received: by 10.237.32.172 with SMTP id 41mr400187qtb.260.1501796978816; Thu, 03 Aug 2017 14:49:38 -0700 (PDT)
Received: from [192.168.1.117] (c-69-140-114-191.hsd1.md.comcast.net. [69.140.114.191]) by smtp.gmail.com with ESMTPSA id a126sm25841150qkf.25.2017.08.03.14.49.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 14:49:37 -0700 (PDT)
To: Aanchal Malhotra <aanchal4@bu.edu>
Cc: dnsop@ietf.org
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>
From: Michael StJohns <msj@nthpermutation.com>
Message-ID: <1214cb8a-54be-68d8-edda-9e1cd804996b@nthpermutation.com>
Date: Thu, 3 Aug 2017 17:49:35 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CAMbs7ku=EoSK5AUULqBQ_T_7piBwhC-GVcacBb3-k01j-ZmVVQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------5E7CFA7EAE7FEC3043821E98"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/gSMtvVqdR9eYY3_GkrJdwh3F1sk>
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 21:49:41 -0000

I answered the question that you asked.  Other people are weighing in on 
the root and stand by keys.

Mike



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 <mailto: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 <mailto:DNSOP@ietf.org>
>     https://www.ietf.org/mailman/listinfo/dnsop
>     <https://www.ietf.org/mailman/listinfo/dnsop>
>
>