Re: [DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt

Paul Wouters <paul@nohats.ca> Fri, 05 November 2021 00:07 UTC

Return-Path: <paul@nohats.ca>
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 B75C23A0779; Thu, 4 Nov 2021 17:07:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 w4TL5-DYW2iP; Thu, 4 Nov 2021 17:07:25 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::85]) (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 767873A0776; Thu, 4 Nov 2021 17:07:25 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4Hlgmn5zwDz3Br; Fri, 5 Nov 2021 01:07:21 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1636070841; bh=UngHNOrwb7X1tHU5kzJoSEiSvt1AnIdHWip5HR2hiG8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=nxsNAJtEyDdJpSCLVITFAH7P6gRqDfc7lez+pD5KiOA3RXXR2O6yhE3XA84XEk0on QzLl3bBfiLo7CTYbGraQrSzTTyKQ0bLeeWY2JXL1RUwrJuDmIDjhc05s/PpYqoXRz5 aZhWCcKB1gSjBUWWfaREatrrHA/+6M61hfRX6l2E=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id ijivWeXPoeUZ; Fri, 5 Nov 2021 01:07:20 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 5 Nov 2021 01:07:20 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 3A906130A25; Thu, 4 Nov 2021 20:07:19 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 371C1130A24; Thu, 4 Nov 2021 20:07:19 -0400 (EDT)
Date: Thu, 04 Nov 2021 20:07:19 -0400
From: Paul Wouters <paul@nohats.ca>
To: Peter Thomassen <peter@desec.io>
cc: "dnsop@ietf.org WG" <dnsop@ietf.org>, dnssec-bootstrapping@ietf.org
In-Reply-To: <91154628-0ca3-15d8-c6bd-b71232b2e64b@desec.io>
Message-ID: <8d3b2ae-70e3-74b4-40a0-70e848acc4aa@nohats.ca>
References: <163520620129.17275.16274772439094875607@ietfa.amsl.com> <91154628-0ca3-15d8-c6bd-b71232b2e64b@desec.io>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/9KHWWBmWyJyy7OxNAl5qshqBJAs>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt
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: Fri, 05 Nov 2021 00:07:31 -0000

On Tue, 26 Oct 2021, Peter Thomassen wrote:

> This draft introduces automatic bootstrapping of DNSSEC delegations. It uses 
> an in-band method for DNS operators to publish information about the zones 
> they host, per-zone and with authentication. With this protocol, DS 
> provisioning can happen securely and without delay.

I've read the draft, and it is an interesting idea. Some thoughts I had:

- Is it really needed to do hashing? Do we really expect domain names to
   hit the 63 or 255 limit ? 
- _boot seems too generic a name for this. _dsbootstrap would be better
   and cause less clashing
- I would like to see some text on removing the records too once the
   child gained its DS record.
- Should it be explicitly noted that in-bailiwick domains are not
   supported?
- It puts a constraint of the nameserver being in a zone that is DNSSEC
   enabled. This is currently not required (though very often the case
   anyway)

In general, the problem is that we need to make it easier for the DNS
hoster to enable DNSSEC when their customers are non-technical. I think
this draft does properly extend RFC 8078 and even think this document
could deprecate the "Accept after wait" method. However, I do think it
should still impose a minimum length of publication before accepting,
so that mistakes similar to the recent slack.com outage can be
prevented. So change "accept after wait" to "verify, then accept after
wait".

Paul