Re: [DNSOP] KSK rollover choices

Michael StJohns <> Wed, 31 October 2018 22:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0D6C6130DF1 for <>; Wed, 31 Oct 2018 15:25:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2LdO_-IFa445 for <>; Wed, 31 Oct 2018 15:25:37 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7EDDF130DEE for <>; Wed, 31 Oct 2018 15:25:37 -0700 (PDT)
Received: by with SMTP id j22-v6so4486617pfh.3 for <>; Wed, 31 Oct 2018 15:25:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=kQHluJAgDny4xWp0GN3+s9NJQch4x1sP5VV6EvNnACA=; b=vWnv+rSMxodRmMWJjLofQDdJ/isxFbz4oe7itpFEi7YOtLRZ0KYv1U/h8rcCT0tjGj YqPpIiDGIjeTLNuHKkunRecOOMn3AWglyPcMHjZjRJEXB0wv2usDsKas4uHh5fGck3sN 6oZDfLI0Q/RLRDFvSsVJGwDIViLqfuXLFtw1uuqLp2YEOyKBeX1Ic8mbh5YuWNawDSMi bDHF+FSv3vH9BVvUi1yVw4k066wGj5ZguXoeEY04Xdf4IbUAzmSdUajypfrOCkfDaG0p EmrcqTbesFHN2JV8OTV1m5WGnHH7zlxAiIWp4e4ITJDdIhyosw75+EB9xzun1XMsZ0sE Nnrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=kQHluJAgDny4xWp0GN3+s9NJQch4x1sP5VV6EvNnACA=; b=BbdEJ2Y0GqSZo3Vi//nbjT8LK7itGsVYbMH8HBeizVdIapJ4FBWcNPa88ndtyDyeTS eEnGtRnFVziNCkZuJ6s4Zg/wNpYrxDaRdYV/Sh/X7dfVelpLJSLOg8mrIstNhgd6TlOE 2PI1pxF/VA7yKTsnwwMjmb+Bh0q+kfzBPB0z6DViOd6ElbJz24aFIkchBJnxGW/9kZyi XUTtv6AxkXyx63NNQbSDzsK7v7CLes8DYgS6rxJsBAFwRARA+T4ejaPRUZw/95sfxI/l OEvJJaJMipI0dEQuJnsEAYYZSSouUyr7MHM/Dh/zVSvcFfcmRg2otXaZ7exnY80hgiXb ab3g==
X-Gm-Message-State: AGRZ1gKKYrP4rONqWD1oIiaL+lbIqIrK6/27nkuq2hQna35rvMh4nIzl ZrAkryf5fE89OQ88koO238Z7T03iLks=
X-Google-Smtp-Source: AJdET5fVkIDdcM3sFa2TA3AXMn/tK+7nBI1zwvEn17T8fWLkYmnACpXc1FJGbOdshecdxgxJnNkSkg==
X-Received: by 2002:a62:3384:: with SMTP id z126-v6mr5276538pfz.112.1541024736431; Wed, 31 Oct 2018 15:25:36 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id d65-v6sm39181012pfm.100.2018. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Oct 2018 15:25:35 -0700 (PDT)
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Michael StJohns <>
Message-ID: <>
Date: Wed, 31 Oct 2018 18:24:52 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [DNSOP] KSK rollover choices
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 31 Oct 2018 22:25:39 -0000

On 10/31/2018 2:54 PM, Paul Vixie wrote:
> Jim Reid wrote:
>>> On 31 Oct 2018, at 00:27, Mark Andrews<>  wrote:
>>> Bootstrap is still a issue.  Over fast TA rolling makes it more of
>>> a issue.
>> Indeed. And that's the underlying problem that needs to be fixed IMO
>> - for instance when/if there's an emergency rollover.
> bootstrappers should have https access to a complete history of root 
> ksk, each one signed by its predecessor. this doesn't handle 
> revocation, but nothing in dnssec handles revocation, and that's by 
> design, and so i'm inclined not to worry about it.
there are at least two things wrong with the above:

1) 5011 provides revocation for ALL keys, not just the root keys, and 
that's by design.  Set the revoke bit on a key, self-sign the RRset with 
that key, and it should prevent trust being traced through the key.
2) the simple history approach will not work.  Simply consider that you 
might need to deal with compromised keys and tell me how I can ensure I 
have ALL the information I need based on a history that can actually 
reflect all types of real world input.   Something like a block chain 
(with yet another set of signatures) over a set of versions of the root 
dnskey RRSet might work, but that will require another chain of trust 
besides the dnssec chain.

> but that's the backup plan. the primary expectation is, devices which 
> come off the shelf after a dnssec ksk roll will have some means of 
> reaching and trusting their manufacturer's software update service, 
> which will offer them a current ksk for validation.

I think the primary expectation should really be the only plan.
> manufacturers who don't last long enough to do this, or who for 
> whatever other reason don't do this, will be shipping future bricks. 
> and i'm fine with that, since it's in their power to do the right 
> thing, which is the best we can offer.
Yup -