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

Peter Thomassen <peter@desec.io> Fri, 17 June 2022 10:17 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 474E0C15AAC6 for <dnsop@ietfa.amsl.com>; Fri, 17 Jun 2022 03:17:39 -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 XVyLf4KlBFsz for <dnsop@ietfa.amsl.com>; Fri, 17 Jun 2022 03:17:34 -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 DED00C14F729 for <dnsop@ietf.org>; Fri, 17 Jun 2022 03:17:34 -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=5jICnxRc1ktaG3C7+YR+n1+snCiWpwVu3su1yhrR3f0=; b=Ac+ptyYv2XZPBz0lHZdFv72ZyC GEGkQ/TwS2LRmd+1ppvDmbPLe+ZTKRtdPzLwIfYWdcbplCnE7Ehn8ipfxElFm5e8lBeVlWOxacXym w0w17ixxYT7uAVneRpMubmfdu9EDvMlE8+wIp/cIDJnss7Q7g18ol6MXFR2GO6zCpJcNHzD4O3GQS SM5ElWx7Yo8RJ2D/IilylIEU/8+qxOMdAtNQ1fD3cWh+OwtBYbANa6IfIQ5bJ/4Nzftnk1mAfKFc0 7xU4KOLHIAPOI36cgmfC/sOAMN6q2NtmsICDrrmuIl6+2gwUP7Dat2JeHvbQcPtvRbwvLlaXrO5hZ MtwPKvvA==;
Received: from pd95ef13a.dip0.t-ipconnect.de ([217.94.241.58] helo=[192.168.176.245]) 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 1o292h-00062W-SC for dnsop@ietf.org; Fri, 17 Jun 2022 12:17:32 +0200
Message-ID: <f7cd3162-166a-e919-b019-42daae1e05b0@desec.io>
Date: Fri, 17 Jun 2022 12:17:31 +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: dnsop@ietf.org
References: <165546037411.59869.5581408796512743719@ietfa.amsl.com>
From: Peter Thomassen <peter@desec.io>
In-Reply-To: <165546037411.59869.5581408796512743719@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/HBd7PqMNEfWp7KtmpOp5Zgkz50M>
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: Fri, 17 Jun 2022 10:17:39 -0000

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

-- 
Like our community service? đź’›
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525