Re: [DNSOP] KSK rollover choices

Joe Abley <> Wed, 31 October 2018 19:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DFB60128BCC for <>; Wed, 31 Oct 2018 12:08:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VnyaQ9xsS4tE for <>; Wed, 31 Oct 2018 12:08:34 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::b34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DBDCA1277C8 for <>; Wed, 31 Oct 2018 12:08:33 -0700 (PDT)
Received: by with SMTP id f15-v6so6613397ybq.13 for <>; Wed, 31 Oct 2018 12:08:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OIwMvYq/Je7fH403m/37SHGVxhEFiN5Fgn87WAeQ/m4=; b=n6lGukTDlClqFn/mxOQ/ksDtHjlP3vW46Y4PWx1KG3Yt3b8vLXMQRxeCmlWncnPajM /Fr4WKMBok3diHkU5VY/tlUAWFHLhcJzUAY70X6RlhLyH1qyockHVfyNS0cRDbVFR5+o ntKHLY7Lm9C5OgO7bQKKmFPjx0FhjVfpwi4B4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OIwMvYq/Je7fH403m/37SHGVxhEFiN5Fgn87WAeQ/m4=; b=dMrmp7qZqQXVnCRuYp/H1APu4ozH9bF8k6A9Q+iAY7VrM+lUds8tdIUeDipZ6O7ur+ 6Bc4VuX2SLvvKc0wknABl67yIiJ4vX3omR7jVEEKVoEBlEe6LeXZ16EgX08qA2LXUTq3 Zuvfiqr/O1g/eC//3PW/ZBU0RE1W3gzlVlqzzvT8jFJITnUuVdEFG2GsOyw8+lN7Hqd6 ra3+7rnSTmmt0GY4jHIqoP+KTrIuuwQm23GmdwYCh8TsonJc2DVa0drvf0txOhqEHs0z 3zGDzzjaQ+WCefbGEb1NERXeBzBZObtjPyY2kCRGR5j2zm/8jCmpkSC4Q4sBilKZdynk vOaw==
X-Gm-Message-State: AGRZ1gK7Dr9o2mXh54FUIDmKgjP5T5TBWDHklLUpY7jvsdmVX5xh+DwY PO+VaEm97KKqyY6S5J83Jsw0BiL5v4k=
X-Google-Smtp-Source: AJdET5dQc3zZVuIqTHSeVVQJBW/NyRdN7yqqi5S0uCi7Q1OutKZDbJOFej5qLWxWDb5SGoMWikYeuQ==
X-Received: by 2002:a25:6c08:: with SMTP id h8-v6mr2397297ybc.452.1541012912945; Wed, 31 Oct 2018 12:08:32 -0700 (PDT)
Received: from ?IPv6:2607:f2c0:101:3:9d59:e8e9:c9ae:e2eb? ([2607:f2c0:101:3:9d59:e8e9:c9ae:e2eb]) by with ESMTPSA id 132-v6sm375056ywf.78.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Oct 2018 12:08:31 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: Joe Abley <>
In-Reply-To: <>
Date: Wed, 31 Oct 2018 15:08:30 -0400
Cc: Jim Reid <>, dnsop WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Paul Vixie <>
X-Mailer: Apple Mail (2.3445.100.39)
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 19:08:36 -0000

Hi Paul,

On 31 Oct 2018, at 14:54, 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.

The existing scheme provides bootstrappers with a complete history of trust anchors (published by digest). The published object was intended to be accompanied by a detached signature that could be trusted by a vendor, since there was to be a certificate chain from the object-signing certificate back to an X.509 trust anchor that made sense to the client (e.g. an iOS code-signing key, a Windows code-signing key, an ISC code-signing key, etc, etc). This is described in RFC 7958.

The only "vendor" that ever published such a certificate was the (largely proof-of-concept) "ICANN" vendor.

I'm not suggesting that the scheme described in that document is good, or that it shouldn't be replaced with something better, but it's one possible starting point for the discussion.