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

"libor.peltan" <libor.peltan@nic.cz> Sun, 19 June 2022 14:42 UTC

Return-Path: <libor.peltan@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 1DE23C15AAFB for <dnsop@ietfa.amsl.com>; Sun, 19 Jun 2022 07:42:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.786
X-Spam-Level:
X-Spam-Status: No, score=-8.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.876, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 c7xrhZrAhQCu for <dnsop@ietfa.amsl.com>; Sun, 19 Jun 2022 07:42:13 -0700 (PDT)
Received: from mail.nic.cz (mail.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 44FB7C15AAF5 for <dnsop@ietf.org>; Sun, 19 Jun 2022 07:42:12 -0700 (PDT)
Received: from [172.21.44.44] (unknown [81.98.213.45]) by mail.nic.cz (Postfix) with ESMTPSA id 510FF14003D; Sun, 19 Jun 2022 16:42:03 +0200 (CEST)
Message-ID: <43a19513-6053-c028-8385-96232315d3c7@nic.cz>
Date: Sun, 19 Jun 2022 16:41:59 +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: Peter Thomassen <peter@desec.io>, dnsop@ietf.org
References: <165546037411.59869.5581408796512743719@ietfa.amsl.com> <f7cd3162-166a-e919-b019-42daae1e05b0@desec.io>
From: "libor.peltan" <libor.peltan@nic.cz>
In-Reply-To: <f7cd3162-166a-e919-b019-42daae1e05b0@desec.io>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.103.4 at mail
X-Virus-Status: Clean
X-Spamd-Bar: ---
X-Rspamd-Server: mail
X-Rspamd-Queue-Id: 510FF14003D
X-Spamd-Result: default: False [-3.10 / 99.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5089, ipnet:81.98.0.0/15, country:GB]; MID_RHS_MATCH_FROM(0.00)[]; BAYES_HAM(-3.00)[100.00%]
Authentication-Results: mail.nic.cz; auth=pass smtp.auth=libor.peltan@nic.cz smtp.mailfrom=libor.peltan@nic.cz
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/U1G4EQlaGIjR9TOpkloRyX_tEFs>
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: Sun, 19 Jun 2022 14:42:17 -0000

Hi Peter, Nils, DNSOP,

In general, I very much like the Bootstrapping idea, and the draft. I 
also like that it now allows in-bailiwick NS (unless in-bailiwick-only).

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.

Thanks for more opinions,

Libor

Dne 17. 06. 22 v 12:17 Peter Thomassen napsal(a):
> Dear DNSOP,
>
> We have addressed the WG's feedback from the Interim on May 24, and 
> also addressed remaining outstanding issues (mainly editorial).
>
> From the authors' perspective, the protocol draft is now "final" (in 
> the sense, that no action items remain). We would appreciate the 
> group's thorough feedback, and -- if the group feels like it -- 
> proceed to WG Last Call
>
>
> The most significant changes are:
>
>> Introduced Signaling Type prefix (_dsboot), renamed Signaling Name 
>> infix from _dsauth to _signal.
>>
>> Allow bootstrapping when some (not all) NS hostnames are in bailiwick.
>
> Due to the first change, DS signaling records now live at names such 
> as: _dsboot.example.co.uk._signal.ns1.example.net
>
>
> Other changes are:
>
>> Clarified Operational Recommendations according to operator feedback.
>>
>> Turn loose Security Considerations points into coherent text.
>>
>> Do no longer suggest NSEC-walking Signaling Domains. (It does not 
>> work well due to the Signaling Type prefix. What's more, it's unclear 
>> who would do this: Parents know there delegations and can do a 
>> targeted scan; others are not interested.)
>>
>> Editorial changes.
>>
>> Added IANA request.
>
>
> On other news, Cloudflare has announced production deployment of the 
> protocol on all their signed domains (see slide 10 of Christian's 
> slides at https://74.schedule.icann.org/meetings/WiPRZ59cBZDvj5ws2).
>
> Thanks,
> Peter
>
>
>
> On 6/17/22 12:06, internet-drafts@ietf.org wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Domain Name System Operations WG of 
>> the IETF.
>>
>>          Title           : Automatic DNSSEC Bootstrapping using 
>> Authenticated Signals from the Zone's Operator
>>          Authors         : Peter Thomassen
>>                            Nils Wisiol
>>     Filename        : draft-ietf-dnsop-dnssec-bootstrapping-01.txt
>>     Pages           : 14
>>     Date            : 2022-06-17
>>
>> Abstract:
>>     This document introduces an in-band method for DNS operators to
>>     publish arbitrary information about the zones they are authoritative
>>     for, in an authenticated fashion and on a per-zone basis. The
>>     mechanism allows managed DNS operators to securely announce DNSSEC
>>     key parameters for zones under their management, including for zones
>>     that are not currently securely delegated.
>>
>>     Whenever DS records are absent for a zone's delegation, this signal
>>     enables the parent's registry or registrar to cryptographically
>>     validate the CDS/CDNSKEY records found at the child's apex. The
>>     parent can then provision DS records for the delegation without
>>     resorting to out-of-band validation or weaker types of cross-checks
>>     such as "Accept after Delay" ([RFC8078]).
>>
>>     This document updates [RFC8078] and replaces its Section 3 with
>>     Section 3.2 of this document.
>>
>>     [ Ed note: This document is being collaborated on at
>> https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/
>> (https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/).
>>     The authors gratefully accept pull requests. ]
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/
>>
>> There is also an HTML version available at:
>> https://www.ietf.org/archive/id/draft-ietf-dnsop-dnssec-bootstrapping-01.html 
>>
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dnssec-bootstrapping-01 
>>
>>
>>
>> Internet-Drafts are also available by rsync at 
>> rsync.ietf.org::internet-drafts
>>
>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>