Re: [DNSOP] IETF meeting prep and what
Vladimír Čunát <vladimir.cunat+ietf@nic.cz> Wed, 23 June 2021 16:28 UTC
Return-Path: <vladimir.cunat+ietf@nic.cz>
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 308163A3CEA for <dnsop@ietfa.amsl.com>; Wed, 23 Jun 2021 09:28:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.238
X-Spam-Level:
X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.338, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 PccnbXA3zkeM for <dnsop@ietfa.amsl.com>; Wed, 23 Jun 2021 09:28:12 -0700 (PDT)
Received: from mail.nic.cz (lists.nic.cz [IPv6:2001:1488:800:400::400]) (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 176183A3CE7 for <dnsop@ietf.org>; Wed, 23 Jun 2021 09:28:11 -0700 (PDT)
Received: from [IPv6:2a02:768:2d1c:226::a2e] (unknown [IPv6:2a02:768:2d1c:226::a2e]) by mail.nic.cz (Postfix) with ESMTPSA id C654D140A03 for <dnsop@ietf.org>; Wed, 23 Jun 2021 18:28:04 +0200 (CEST)
To: dnsop@ietf.org
References: <CADyWQ+ESB-W9DvdRjCrdXgaZUWzX5b5cUvu-Ue3zjRrVsnCB2w@mail.gmail.com> <5a9b35c5806e36b0802be493d87beb8ef2fef18d.camel@powerdns.com>
From: Vladimír Čunát <vladimir.cunat+ietf@nic.cz>
Message-ID: <f3d4290f-ea9e-f219-308a-5bf92ccead24@nic.cz>
Date: Wed, 23 Jun 2021 18:28:04 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <5a9b35c5806e36b0802be493d87beb8ef2fef18d.camel@powerdns.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.102.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/AYhlyZkguCNGE8Sv8iOMI65E8Bs>
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: Wed, 23 Jun 2021 16:28:15 -0000
On 18/06/2021 19.40, Peter van Dijk wrote: > aname can go; I trust the WG feels SVCB will supersede it. Yes, please. > I propose replacing rfc5011-security-considerations with a short document deprecating 5011 in its entirety. I am happy to write text for that, if there is an appetite - when the WG queue is small enough! I agree that 5011 doesn't seem really useful (anymore). We have it in Knot Resolver but recommend not to use it, because it's just more trouble than worth in practice. Notably, (all) resolver software needs much more frequent updates than the rate of root KSK rollovers, so it's easier to distribute root DS within the updates; some Linux distros even package these separately and share them among different resolver packages. Even if you're conservative and use BIND ESV or similar, I believe it's a better approach than 5011. For non-root keys there doesn't seem much point nowadays, as getting a chain from root is better. (By the way, an "interesting" example: router with DNSSEC validation and factory reset / rollback, commonly shelved for a year, unreliable clock, etc.) --Vladimir
- [DNSOP] IETF meeting prep and what Tim Wicinski
- Re: [DNSOP] IETF meeting prep and what Warren Kumari
- Re: [DNSOP] [Ext] IETF meeting prep and what Paul Hoffman
- Re: [DNSOP] [Ext] IETF meeting prep and what Paul Wouters
- Re: [DNSOP] IETF meeting prep and what Peter van Dijk
- Re: [DNSOP] IETF meeting prep and what Paul Wouters
- Re: [DNSOP] IETF meeting prep and what Joe Abley
- Re: [DNSOP] IETF meeting prep and what Paul Wouters
- Re: [DNSOP] IETF meeting prep and what Joe Abley
- Re: [DNSOP] IETF meeting prep and what Wes Hardaker
- Re: [DNSOP] [Ext] IETF meeting prep and what Paul Hoffman
- Re: [DNSOP] [Ext] IETF meeting prep and what Paul Hoffman
- Re: [DNSOP] [Ext] IETF meeting prep and what Daniel Migault
- [DNSOP] Review of draft-ietf-dnsop-rfc5011-securi… Paul Wouters
- Re: [DNSOP] [Ext] IETF meeting prep and what Tim Wicinski
- Re: [DNSOP] [Ext] IETF meeting prep and what Shumon Huque
- Re: [DNSOP] IETF meeting prep and what Anthony Eden
- Re: [DNSOP] [Ext] IETF meeting prep and what Michael StJohns
- Re: [DNSOP] Review of draft-ietf-dnsop-rfc5011-se… Michael StJohns
- Re: [DNSOP] IETF meeting prep and what Vladimír Čunát
- Re: [DNSOP] IETF meeting prep and what Joe Abley
- Re: [DNSOP] IETF meeting prep and what Brian Dickson
- Re: [DNSOP] IETF meeting prep and what Peter van Dijk
- Re: [DNSOP] IETF meeting prep and what Joe Abley
- Re: [DNSOP] IETF meeting prep and what Michael StJohns
- Re: [DNSOP] IETF meeting prep and what Mark Andrews
- Re: [DNSOP] IETF meeting prep and what Michael StJohns