Re: [DNSOP] KSK rollover choices

Joe Abley <jabley@hopcount.ca> Thu, 01 November 2018 19:32 UTC

Return-Path: <jabley@hopcount.ca>
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 5B72F12896A for <dnsop@ietfa.amsl.com>; Thu, 1 Nov 2018 12:32:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 XaEpbGbfacvR for <dnsop@ietfa.amsl.com>; Thu, 1 Nov 2018 12:32:33 -0700 (PDT)
Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 DDF08124BAA for <dnsop@ietf.org>; Thu, 1 Nov 2018 12:32:32 -0700 (PDT)
Received: by mail-it1-x136.google.com with SMTP id r5-v6so86979ith.2 for <dnsop@ietf.org>; Thu, 01 Nov 2018 12:32:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Mf5O0W+HmySCCU4h0CtKNCsx8nRIhGFGzgsDAvTJd7c=; b=VYxgWC/Jjz6l56quAoiQUVbsLE85JoZxD0vJRZ9DSsLe/JaEqkJGR458K28sTHvbd9 s+mbGk0Ob6Nj2xCwSXNWh3U31JoG9Xhl29kSA6Zmg/dX3slH+t9DOA5TxKF+DfqKHrXO TTCMpGCRenhQ961zCao5nXzFRaAXjAFdFq62c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Mf5O0W+HmySCCU4h0CtKNCsx8nRIhGFGzgsDAvTJd7c=; b=l9eWZoSGbFefejCK3tZiorwbODS3PaH6EMTj9rpd9WqI/Ygl/Qukm6ekeLgBSY5Xkg EV7xqrEZ7aIBEWm1qcT8+Dc9ihcM45ONkLdn/FvtKRbtw/tUJ6sw7GwsRSgxUDURM1NY QG3R3qhflMDaZlHAWmoM0A3vM2D3hZy5W2kMZmlqHILDNAHbOu7nhi3DJ2VmcGJkaPEe Gu5HBbu6rE5Q1hCm8+cBU8iE3l+ToKkPF9FtzQDySsM5vRvP/VusMJ2pu64N35PTBgJz IlOxvQ8Al80mY4igNrOE8VhnpuyG3Eqn87cRqT1nowYfRfHDswWhXuJvIfPkK0sGiObj TmdQ==
X-Gm-Message-State: AGRZ1gJk6RQ5GwEhsyGkcPrZHnxo6y5XqfNHV0EJ1ogS85pe+sMyMTxr 2vLfn+oSY6ZgyWdOzvnwOkMYUXDWHLM=
X-Google-Smtp-Source: AJdET5cvRJ5K+4oz3mZYzt4pNs0pVo1X0UNCedDVGBykMLFnYlCvQkUSz3PxP/I9fgPcXP9cNSos4A==
X-Received: by 2002:a24:3688:: with SMTP id l130-v6mr5603886itl.88.1541100752016; Thu, 01 Nov 2018 12:32:32 -0700 (PDT)
Received: from ?IPv6:2607:f2c0:101:3:6c29:1cd6:580e:5400? (node-131dv4hpok1rdj5s00.ipv6.teksavvy.com. [2607:f2c0:101:3:6c29:1cd6:580e:5400]) by smtp.gmail.com with ESMTPSA id a17-v6sm7049028ioc.28.2018.11.01.12.32.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Nov 2018 12:32:30 -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 <jabley@hopcount.ca>
In-Reply-To: <yblin1gzk2d.fsf@w7.hardakers.net>
Date: Thu, 01 Nov 2018 15:32:29 -0400
Cc: Russ Housley <housley@vigilsec.com>, dnsop WG <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <15E0A051-6C3E-4191-AB0E-97334040B9A4@hopcount.ca>
References: <00E03DAE-9403-49B2-8489-6F7F35D18534@icann.org> <CAJhMdTP-bh1yeOOCS+08rAMhkgyk6yZa9tpQvZ36rR7N=RoQow@mail.gmail.com> <23511.13515.365128.519464@gro.dd.org> <23511.14092.990015.593983@gro.dd.org> <CABf5zv+1XFPWaaX1x=W5pAK7rC4HYQ2OsQ4vvoADgKaQufjmBw@mail.gmail.com> <A800B089-EC3C-4DEF-95FD-3314ACB311A5@hopcount.ca> <CABf5zvL=VJdzJybYGR6pQFpapS=A9nQuPK-+vR2T7cptRkx5AQ@mail.gmail.com> <alpine.DEB.2.20.1810301103240.24450@grey.csi.cam.ac.uk> <A54BF075-89AB-4460-B0B8-15BA18C5DC18@isc.org> <E67B15B3-76EB-4857-B400-4CEAA4E46E78@rfc1035.com> <3C97B346-B042-41D3-8E32-CFE17F305DE1@isc.org> <20A6D389-C460-45B6-821D-BDDA6E8FD47E@vigilsec.com> <yblin1gzk2d.fsf@w7.hardakers.net>
To: Wes Hardaker <wjhns1@hardakers.net>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/UbdkYOkfeatRu8SHDNnfq0MYk0M>
Subject: Re: [DNSOP] KSK rollover choices
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 01 Nov 2018 19:32:34 -0000

On 1 Nov 2018, at 15:14, Wes Hardaker <wjhns1@hardakers.net> wrote:

> Russ Housley <housley@vigilsec.com> writes:
> 
>> It is a good time to do rfc5011-bis.  Real world experience from the
>> KSK roll makes a lot os sense to me.
> 
> I think step one would be to list the aspects of it that worked well,
> and the aspects that didn't.  From that we can determine the need for a
> replacement and what features would be needed in order to accommodate the
> aspects that didn't work well.  I do believe it worked quite well over
> all, but there are elements that were lacking and may be worth doing a
> bis to address.  [but we really need a upsides-and-downsides list based
> on experience first in order to evaluate the need to do a bis].

I'm not sure that "5011bis" is a helpful way to phrase this.

5011 solves the area it is concerned with (conventionally long-lived devices that don't ship on the shelf for long periods) very nicely, as far as I can see. There have been some variable implementations that might suggest the need for improved clarity in the specification or better test suites or something, but I don't think our recent experience has provided clear signs that 5011 as a protocol is deficient or unsuitable.

I think the wider problem space might be better described as trust anchor publication and retrieval. Within that perimeter we can find scope for improvement in areas like emergency key rollover, pre-publication of trust anchors for standby keys, retrieval of trust anchor (bootstrapping) by ephemeral or unattended devices, etc, etc. The area that 5011 addresses is kind of the best part.


Joe