Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements

Florian Obser <florian+ietf@narrans.de> Sun, 27 November 2022 12:26 UTC

Return-Path: <florian+ietf@narrans.de>
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 B5CFFC14CE2D for <dnsop@ietfa.amsl.com>; Sun, 27 Nov 2022 04:26:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMyzv4sNxCfL for <dnsop@ietfa.amsl.com>; Sun, 27 Nov 2022 04:26:44 -0800 (PST)
Received: from imap.narrans.de (michelangelo.narrans.de [45.77.55.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA512) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 424A0C14F718 for <dnsop@ietf.org>; Sun, 27 Nov 2022 04:26:42 -0800 (PST)
Received: from pinkunicorn (2001-1c00-270d-e800-dd76-615f-61ca-d6aa.cable.dynamic.v6.ziggo.nl [2001:1c00:270d:e800:dd76:615f:61ca:d6aa]) by michelangelo.narrans.de (OpenSMTPD) with ESMTPSA id b80c0fc1 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sun, 27 Nov 2022 13:26:36 +0100 (CET)
From: Florian Obser <florian+ietf@narrans.de>
To: Daniel Migault <mglt.ietf@gmail.com>
Cc: dnsop@ietf.org
References: <CADyWQ+FwRaSdpSWXBDqCG9ZPNPiG4pGUx37PVtExbqVPr5ZfmA@mail.gmail.com> <65d26b98-e0d6-e69b-10d4-17632451cab6@nic.cz> <CADZyTk=wUydEv4X8KgHe3Mj0cZTmiaR3mjn_Z2n73U-eST-HPA@mail.gmail.com> <f397b7d4-fe4f-6000-5ce5-f2faa7b27b3e@nic.cz> <CADZyTkkdn__VhRRqwKDbNx3ymTR0KJmxoTN9aKMcox-JS=pW_A@mail.gmail.com>
Date: Sun, 27 Nov 2022 13:26:35 +0100
In-Reply-To: <CADZyTkkdn__VhRRqwKDbNx3ymTR0KJmxoTN9aKMcox-JS=pW_A@mail.gmail.com> (Daniel Migault's message of "Fri, 25 Nov 2022 12:26:18 -0500")
Message-ID: <m1wn7gd1ms.fsf@narrans.de>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (darwin)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/qCWaDkW8B9MNVlOasM8RcAc_2xA>
Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
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: Sun, 27 Nov 2022 12:26:46 -0000

On 2022-11-25 12:26 -05, Daniel Migault <mglt.ietf@gmail.com> wrote:
> On Wed, Nov 23, 2022 at 10:29 AM Vladimír Čunát <vladimir.cunat+ietf@nic.cz>
> wrote:
>> I am surprised  you would not recommend RFC 5011
>>
>> 5011 needs persistent state, a thing that resolvers/validators often don't
>> need at all otherwise (cache is safe to delete).  5011 doesn't always work,
>> so you need to combine with some fallback mechanism(s) anyway - for new
>> installations and for stale ones (missed rotation).  Root rollover has
>> happened only once in history, non-root TAs aren't that common, and 5011
>> algorithm isn't very simple, so the code can easily get some bugs without
>> anyone noticing until it's too late.
>>
>> Lots of down-sides, so I rather put the TAs into SW updates, for the root
>> TA case at least.  I'd recommend trying to avoid non-root TAs, but if I had
>> to choose, I'd put them into configuration.  Again a thing that I have to
>> provision *anyway*, so I get the occasional TA updates basically for free,
>> without needing to worry about those 5011 disadvantages.  (occasional =
>> 5011 defaults to requiring 30 days of overlap)
>>
>>
> Oh! sure for the TA. My understanding of the text is that it recommends
> 5011 for running instances, but that new instances are configured with
> up-to-date TA that in most cases are updated by software update. So yes I
> agree and will check this appears clearly.

Another issue with 5011 is that it needs cooperation from the entity
signing the zone during a KSK rollover. 7583 spells this out in section
2.2. I think Vladimír is hinting at this already, I'd say it should be
spelled out. Especially since this is aimed at non-DNSSEC-Experts as you
were saying earlier in the thread.

If a DRO unilaterally decides to put in a TA for example.com as
suggested in section 7.1.1 and using 5011 this will not end well if they
don't tell the people operating the signer. They will probably not
follow the correct timing during a KSK roll.