IETF Logo Mail Archive

Re: [DNSOP] IETF meeting prep and what

Paul Wouters <paul@nohats.ca> Fri, 18 June 2021 20:37 UTC

Return-Path: <paul@nohats.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 447D93A0BCC for <dnsop@ietfa.amsl.com>; Fri, 18 Jun 2021 13:37:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.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 IMECz27O09pp for <dnsop@ietfa.amsl.com>; Fri, 18 Jun 2021 13:36:59 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 327E83A0BCB for <dnsop@ietf.org>; Fri, 18 Jun 2021 13:36:58 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4G69h71YbWzCw4; Fri, 18 Jun 2021 22:36:55 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1624048615; bh=/0k3n9RESWl23l++gCD4x9PzSD/6q1kLuNxMmzyTsiI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=SYN8jcUwuQX56mCvbBsWFci8un/QJ8N/1lbD94CfjU2b3Lcg8g6QrSAQLy3WV/mAr J8dWSHBXmdjUYL632YqKfckjbcwO70Er0P6YItbJ+jN9kGQPXWuN4ML4ZjgA7TPho2 5igyYnMDrVGdKn/iK4PLdFPTj7rCM2hz0ncEnC9g=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id DqVPPrGaa8EO; Fri, 18 Jun 2021 22:36:53 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 18 Jun 2021 22:36:53 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id CAA238597D; Fri, 18 Jun 2021 16:36:51 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C39358597C; Fri, 18 Jun 2021 16:36:51 -0400 (EDT)
Date: Fri, 18 Jun 2021 16:36:51 -0400
From: Paul Wouters <paul@nohats.ca>
To: Joe Abley <jabley@hopcount.ca>
cc: Peter van Dijk <peter.van.dijk@powerdns.com>, dnsop <dnsop@ietf.org>
In-Reply-To: <3CB2EC32-E53D-4D08-8431-F7B6AD68D004@hopcount.ca>
Message-ID: <a895ee1-67f4-d6a0-a256-a4b1d3304efb@nohats.ca>
References: <5a9b35c5806e36b0802be493d87beb8ef2fef18d.camel@powerdns.com> <A7A0319B-2DB5-49F7-9E8C-A0065157D14A@nohats.ca> <3CB2EC32-E53D-4D08-8431-F7B6AD68D004@hopcount.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/NtwxkDazawZs0N-En16fXQoauqs>
Subject: Re: [DNSOP] IETF meeting prep and what
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: Fri, 18 Jun 2021 20:37:04 -0000

On Fri, 18 Jun 2021, Joe Abley wrote:

>> On Jun 18, 2021, at 13:41, Peter van Dijk <peter.van.dijk@powerdns.com> wrote:
>>
>>> I propose replacing rfc5011-security-considerations with a short document deprecating 5011 in its entirety.
>>
>> Eh? 5011 is baked into various software. Why would replace 5011 ?
>>
>> Did I miss something?
>
> There were some conversations adjacent to the last great root zone KSK roll excitement about how a more measurable and reliable mechanism might be useful. My memory is that there might be value in specifying a new mechanism that could be used as an alternative to or in conjunction with 5011, though, not that 5011 was fundamentally unsound and deserved to be deprecated.
>
> I agree that, in the end, 5011 seems to have done a reasonable job -- it was just hard to predict with any degree of comfort or certainty.

Sure, but if we were to deprecate 5011, what would we expect to happen
when we want to do another rollover ? We would still have software out
there doing 5011, so we can't do it dramatically different. Which
would lead me to think at best we could do a 5011bis that's mostly
compatible but somehow improved on what we missed, the reporting.

But that is quite different from "deprecating 5011 in its entirety".

Paul "no-not-a-dns-flagday" Wouters

v2.14.0 | Report a Bug | By Email