Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bootstrapping-01.txt

Peter Thomassen <peter@desec.io> Wed, 22 June 2022 10:40 UTC

Return-Path: <peter@desec.io>
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 C9B7FC14F72A; Wed, 22 Jun 2022 03:40:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.785
X-Spam-Level:
X-Spam-Status: No, score=-3.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-1.876, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=a4a.de
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 ZDF_vw4-AK6B; Wed, 22 Jun 2022 03:40:08 -0700 (PDT)
Received: from mail.a4a.de (mail.a4a.de [IPv6:2a01:4f8:10a:1d5c:8000::8]) (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 3B90BC14F726; Wed, 22 Jun 2022 03:40:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=a4a.de; s=20170825; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:Subject:From :References:To:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=1K7ZP29bdGY0+n7y3Fv+fQGvyoCrpg0sUNalSs/40tI=; b=CTLbhyLHNbpY0hQDqrBDQjofKz tbmqR/WiN1thJvZ8Tw8yhMVj5yl5Zrq5n2lmbMbpzaibc0e0I+mQq4hv4mHE6CUrJ2ilGVQODV8Ev K2/Knfxzvep05x2AdgLQ4YzEJPN/fpmAt/88k0CFrgc+6hXIhqau2/nuf7t/UHFqYDujmZ2/KCO8L C9TPPFtgPgH/fyCEsTlSrq6y2vZb52p9c0zycTabOgrzB7znwzPCJi+unLsCJyVxlElh+RRY2bL7b etiocEIVDdQlRjAYKkQzXts7rkYPli8P2iQ+69li32yrCpIzk36mAiQg8h/H+3ana5gEXucW6vwx9 JeI1eHYg==;
Received: from ip5f5bf78b.dynamic.kabel-deutschland.de ([95.91.247.139] helo=[192.168.179.3]) by mail.a4a.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <peter@desec.io>) id 1o3xmA-0001QF-Su; Wed, 22 Jun 2022 12:39:59 +0200
Message-ID: <627a6aca-6d1d-3968-f095-c25802735522@desec.io>
Date: Wed, 22 Jun 2022 12:39:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1
Content-Language: en-US
To: "libor.peltan" <libor.peltan=40nic.cz@dmarc.ietf.org>, dnsop@ietf.org
References: <165546037411.59869.5581408796512743719@ietfa.amsl.com> <f7cd3162-166a-e919-b019-42daae1e05b0@desec.io> <43a19513-6053-c028-8385-96232315d3c7@nic.cz>
From: Peter Thomassen <peter@desec.io>
In-Reply-To: <43a19513-6053-c028-8385-96232315d3c7@nic.cz>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ZJfQb612nyPPLEp6P3JNJSGwbLo>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bootstrapping-01.txt
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: Wed, 22 Jun 2022 10:40:12 -0000

Libor,

On 6/19/22 16:41, libor.peltan wrote:
> However, I'd like to discuss if it really should *replace* RFC8078, Section 3 whatsoever.
> 
> Sure, it's definitely more secure than the rather quirky Accept after Delay/Checks/Challenge procedures, but it adds also more limitations, as described in section 3.4 anyway.
> 
> I would prefer if both options remained standardized in parallel, so that anyone can choose between more secure, or more universal way of DNSSEC bootstrapping.
> 
> Alternatively, we may say that the RFC8078 bootstrapping is deprecated, but still, it doesn't mean that we replace it.

I understand the concern, and I believe that at least those parents which already do implement unauthenticated RFC 8078 bootstrapping (e.g. "accept after delay") should not immediately run into a situation where the spec is violated. Some parents may also have other reasons for supporting a less secure method.

So I agree that strictly "replacing" Section 3 may be too much, but we should strongly discourage its use. Perhaps its enough to state that the draft "obsoletes" (or "deprecates"?) RFC 8078 Section 3?

If we do so, the current draft still has Section 3, which says:
> Child DNS Operators and Parental Agents who wish to use CDS/CDNSKEY records for DNSSEC bootstrapping SHOULD support the authentication protocol described in this section.

... so this already leave some wiggle room to do things differently.

Any preferences on the wording?

Thanks,
Peter

-- 
https://desec.io/