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

Warren Kumari <warren@kumari.net> Thu, 03 August 2017 19:51 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 50792129B26 for <dnsop@ietfa.amsl.com>; Thu, 3 Aug 2017 12:51:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 Ftxk0ky6lr9b for <dnsop@ietfa.amsl.com>; Thu, 3 Aug 2017 12:51:54 -0700 (PDT)
Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (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 1E9F9129A84 for <dnsop@ietf.org>; Thu, 3 Aug 2017 12:51:54 -0700 (PDT)
Received: by mail-ua0-x230.google.com with SMTP id w45so10734049uac.5 for <dnsop@ietf.org>; Thu, 03 Aug 2017 12:51:53 -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:content-transfer-encoding; bh=un7qiHMHmdqccEGqb9iUfq2eI4/HubN7PxKLZFuEOs8=; b=E+U0o11BoG9C6FIKBeLUGTnyqlm+49FzwsyScLVtAKnya+OwiHQluxGU/BQo/W78Lf 7DIYy0/D7kbd9IBLF+ojd8TpdgPOHx82BIuGU8YGXibHId4A03OmPFShV2U80bde6aLV thLLY8kgbzGdkD9eQioMj4sz8vShrcNRry45YRB/74TpBWrpW0ro95SeQeUPje11p+m8 PGMSr32GXkrcbuehYDjuNiEnoJO75TqjyUzLBg04hJ/Kg6yCrNeRrvxIr8ofRdU6iCiD dZQGb4qo2v4nsPgpP4Xo7YQfPlcIngwID8zNolLkjUFFgfRYH/41BwEjp6pglpevnCMJ K0DQ==
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:content-transfer-encoding; bh=un7qiHMHmdqccEGqb9iUfq2eI4/HubN7PxKLZFuEOs8=; b=Py9DsRJfI2yYso6rLOWMtN+eE7kmDMIXy2d3N17VYvL9gXW/3kKGyQb1pYIeGNyO6W OONtXgoi3wzFfeDeh5tuqWHf/9pt40It/Db8xiY81RToOD6pA47yCBi5sFgjeq1Cdm9q D2UlHKNbfXcErLvX1a7MVcrzqsBqBh0N9OfCzQghlw0F7x5yNFtbySmtbtF1rMlJbuX5 iLdy1JNHYKlkhItpOBEDMDY5yB/hCBuR7HbVagUNUViiERgMMTcI4B3dFo+6ugwRRSN7 zfhwgOB40SXWymR8F96XN+DRdks0So//bXwZmAWGUMuVaLuFACt4NDBF9aw0yeMvPCiX TRww==
X-Gm-Message-State: AIVw110QknBtdUyjgen5K1iDk7lfVheY+yO7lNHBZYJB87FDWnvmENqn hg5WYu1tMBE8kTN1rPa6W2UwaSduKn+D
X-Received: by 10.176.9.75 with SMTP id c11mr1959347uah.145.1501789912958; Thu, 03 Aug 2017 12:51:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.9.231 with HTTP; Thu, 3 Aug 2017 12:51:12 -0700 (PDT)
In-Reply-To: <CAMbs7kuUMgXsvhG90zP=b+dL30oG0OQQwpGiBnE+e_FNXMvFgQ@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>
From: Warren Kumari <warren@kumari.net>
Date: Thu, 3 Aug 2017 15:51:12 -0400
Message-ID: <CAHw9_iLqJS_H0fWy4rDWbMz-s6iFNxVe+sCVgPRMcti4czh0Kg@mail.gmail.com>
To: Aanchal Malhotra <aanchal4@bu.edu>
Cc: "Rose, Scott" <scott.rose@nist.gov>, dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/PN5JoWTShO30iCmVdfATaYa5mKc>
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:51:56 -0000

On Thu, Aug 3, 2017 at 3:01 PM, Aanchal Malhotra <aanchal4@bu.edu> wrote:
> Hi Scott,
>
> Thanks for the response. I have another question in that case. Please see
> below.
>
>
> On Thu, Aug 3, 2017 at 6:17 PM, Rose, Scott <scott.rose@nist.gov> wrote:
>>
>> Hi,
>>
>> (800-81 author here)
>>
>> That needs to be updated as it was from the earlier revision of 800-81. It
>> really should stress the use of RFC 5011 automated trust anchor update
>> process. The first version of the doc assumed RFC 5011 was not available in
>> the majority of implementations, which is not the case now. I’d probably
>> update that to recommend (and stress) to always use the RFC 5011 rollover
>> process.
>>
>> As for emergency rollovers, some admins do worry about it and plan for it
>> by having a pre-published KSK in the DNSKEY RRset at all times (not just
>> during an actual rollover process). RFC 5011 can be used there too (see the
>> “Scenarios” section in RFC 5011).
>
> 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?

Yeah, 5011 as currently used does very little for emergency rollovers.
An attacker who has compromised a key can indeed continue to keep
their foothold (or possibly increase it) through the 5011 roll.
RFC5011 is only intended for scheduled rollovers, and the old key
needs to be revoked "shortly" after the new one is introduced.
The timing of all this is, er, subtle - see
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/
for some of it...


The plan at one point was to have 2 trust anchors, a primary one
(being used for signing) and a backup one, which would be published,
but not used for signing. If the primary is suspected to be
compromised, the backup one can start to be used, and the primary
revoked. This would buy some time to figure out what happens next :-P
There has been much discussion over the years if this makes things
safer or not -- having 2 times as many keys means that a (brute-force)
attacker it more likely to be able to factor a key, it is unclear
under what scenarios the primary would be compromised while still
maintaining trust is the backup, etc....

W

>
>>
>> There isn’t a single doc that focuses on KSK rollovers, but it is
>> discussed in the BCP docs like RFC 6781 and other implementation-specific
>> documents.
>>
>> Scott
>>
>>
>> On 3 Aug 2017, at 11:50, Aanchal Malhotra 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
>>
>>
>> ===================================
>> Scott Rose
>> NIST ITL
>> scott.rose@nist.gov
>> +1-301-975-8439
>> GV: +1-571-249-3671
>> ===================================
>
>
>
> _______________________________________________
> 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