[DNSOP]Re: Intdir telechat review of draft-ietf-dnsop-dnssec-bootstrapping-08
Peter Thomassen <peter@desec.io> Wed, 15 May 2024 12:23 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 1F3EEC1DA2F8; Wed, 15 May 2024 05:23:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 9hLXz1DRiucr; Wed, 15 May 2024 05:23:07 -0700 (PDT)
Received: from mail.a4a.de (mail.a4a.de [IPv6:2a01:4f8:10a:1d5c:8000::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFF97C1E701F; Wed, 15 May 2024 05:23:06 -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:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: 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=LfJXTslMumcM7wE8YoslDopz0y8IksJeyWpw4FOry/o=; b=NWqh2pRnqHGMBJU1NDLj89RcEZ Oyq73PomG+DwbZQ5KxAL0qS3Z6r3qB1KSusZsyjvn6cLlCalqcaL+z8kHII4GfcWRuzSXn9vN0rl2 I4PTdwojodoIgCOYtgf/yRDaGq92g+J4CI2Qw6/l0KUjrg2If/1zwt218+GBuJTvd2/xmDnV+Im5D agdRNPNO8P7zVLiydd/JYPMbokRiAcZZioqx0ZxX26xGVRWAf9Nf9tyuj7xsJH7j/5phviuO5/5E9 dymOh1eNupbIEKXJ/8fvoGcnoXZi0FuOgsojyBwUwZaYAernpC0/vaCgIC5R9jevuwUUEsMwG/Nnt R8tbp1Tg==;
Received: from [2a02:8109:9283:8800:c2b3:de5c:d8fe:c102] by mail.a4a.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <peter@desec.io>) id 1s7Dex-004DD1-8N; Wed, 15 May 2024 14:23:03 +0200
Message-ID: <cc26f1c5-2628-4e5f-a04e-f869bf43caf0@desec.io>
Date: Wed, 15 May 2024 14:23:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Benson Muite <benson_muite@emailplus.org>, int-dir@ietf.org
References: <171553939119.13322.12950960334297290558@ietfa.amsl.com>
Content-Language: en-US
From: Peter Thomassen <peter@desec.io>
In-Reply-To: <171553939119.13322.12950960334297290558@ietfa.amsl.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Message-ID-Hash: PFB7WLIDW5PNUEIEFIRHMCBBEOIWQL35
X-Message-ID-Hash: PFB7WLIDW5PNUEIEFIRHMCBBEOIWQL35
X-MailFrom: peter@desec.io
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: dnsop@ietf.org, draft-ietf-dnsop-dnssec-bootstrapping.all@ietf.org, last-call@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP]Re: Intdir telechat review of draft-ietf-dnsop-dnssec-bootstrapping-08
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/tAUqHzUc5pqhxLozBTVpWNL6ckM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>
Hi Benson, Thank you for your review. On 5/12/24 20:43, Benson Muite via Datatracker wrote: > Reviewer: Benson Muite > Review result: Ready with Nits > > I am an assigned INT directorate reviewer for > <draft-ietf-dnsop-dnssec-bootstrapping-08.txt>. These comments were written > primarily for the benefit of the Internet Area Directors. Document editors and > shepherd(s) should treat these comments just like they would treat comments > from any other IETF contributors and resolve them along with any other Last > Call comments that have been received. For more details on the INT Directorate, > see https://datatracker.ietf.org/group/intdir/about/ . > > Based on my review, if I was on the IESG I would ballot this document as YES. > > SUMMARY: > The draft proposes a mechanism to enable automated initial validation of child > subdomain CDS/CDNSKEY records when an out of balliwick name server is available > and when the child zone name is not too long. > > SUGGESTIONS FOR IMPROVEMENT: Incorporated changes will show up in the -09 revision (will be published later today) and are part of this PR: https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/pull/15 > 1. May want to minimize number of acronyms in the abstract, for example DS > (Delegation Signer), CDS (Child DS) and CDNSKEY (Child Domain Name System > public key) Those terms are identifiers for DNS record types, rather than acronyms. As a salient example, the TLSA record type "does not stand for anything" (RFC 6698 Section 1.2). As such, they are typically not expanded in DNS-related RFCs (see for, for example, RFC 8078 whose abstract uses DS and DNSKEY as well without expansion). > 2. Too long is not specified though is mentioned in section 4.4 - > could more details be given We've added a reference to RFC 1035 Section 3.1 which defines these length requirements. > and do deprecated out of band methods need to be > used in such cases? The document deprecates automatic DNSSEC bootstrapping without authentication. If it can't be done automatically with authentication, one can set up DS records manually (by interacting with the parent operator). To do it securely, an out of band channel may be needed (e.g., via the registrar's web interface). One does not have to use a deprecated (insecure) automated method. > Any estimates on how often too long names might occur? I'm not aware of any numbers. It essentially happens when the _dsboot and _signal labels together with the domain name and longest nameserver hostname exceed 255 octets. As both nameserver names and delegated domain names are usually shorter than ~120 octets, this is expected to happen very rarely in practice. We don't have numbers, unfortunately, but I wouldn't be surprised if the only real examples are experiments set up to prove the point. > 3. > Will there be a follow on informational best practice document based on > operational experiences? Saying this is not in scope for the spec document, but yes, various people (including some ICANN staff) have expressed interest in writing up best practices / operational experience on DNSSEC automation, including (but not limited to) the topic of bootstrapping. Thanks, Peter -- https://desec.io/
- [DNSOP]Intdir telechat review of draft-ietf-dnsop… Benson Muite via Datatracker
- [DNSOP]Re: Intdir telechat review of draft-ietf-d… Peter Thomassen
- [DNSOP]Re: Intdir telechat review of draft-ietf-d… Benson Muite