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

Peter Thomassen <peter@desec.io> Wed, 22 June 2022 10:29 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 0E26BC14F720 for <dnsop@ietfa.amsl.com>; Wed, 22 Jun 2022 03:29:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.773
X-Spam-Level:
X-Spam-Status: No, score=-3.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-1.876, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_TEMPERROR=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 TJlCyZK4tcwj for <dnsop@ietfa.amsl.com>; Wed, 22 Jun 2022 03:29:42 -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 8DCA2C14F6E7 for <dnsop@ietf.org>; Wed, 22 Jun 2022 03:29:42 -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=3A6jQ2m2Y9qeiWCs3DvmwFn4OvIJxTfmpDl21vUJEUk=; b=mvccrNVgpCQfITlh+nsoakwL2J bdtzVBy/blt8z8K6aUGZpdn50WgaqyaCJ7Pq+T8LqIsCko8arx47mRIkOC7HWJHcKrzWgqKGZfh00 9lhP5oB9RFukdnwS8AqDPV5HLSGjFEdN1GonIB1osqoFCyBvE4a1IFphaSBsw+M7suqOTr5rmEayv QLNEXvcrHp9rZqew8xF5PhjfRGXcY5lgwwbCeOckU3F/BnOVj3rru66+RBO0ZkgaIuYNIca3Ax7Kr CSuhTao/jwq+vM0SdL8xanPcHxanZNvtwh+KU+RTOtbD5989MmsEbw+TmkAMyfPg4go+BPVFhPtav TOgZJofA==;
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 1o3xcA-0000NW-T4 for dnsop@ietf.org; Wed, 22 Jun 2022 12:29:39 +0200
Message-ID: <953b6f31-3340-cb9d-0c1c-0463fe09fd26@desec.io>
Date: Wed, 22 Jun 2022 12:29:38 +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: <20220619173030.8B19743D3B6E@ary.qy>
From: Peter Thomassen <peter@desec.io>
In-Reply-To: <20220619173030.8B19743D3B6E@ary.qy>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/kr7uLM7aGTb5PpT_vc0ToiqLG4s>
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:29:47 -0000

Hi John,

On 6/19/22 19:30, John Levine wrote:
> It appears that libor.peltan  <libor.peltan@nic.cz> said:
>> Alternatively, we may say that the RFC8078 bootstrapping is deprecated,
>> but still, it doesn't mean that we replace it.
> 
> That seems reasonable.  Does anyone actually do the current TOFU-ish bootstrap?

Yes: https://github.com/oskar456/cds-updates

>>>> 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.)
> 
> There's still a reference to NSEC walking in the penultimate paragraph in sec 3.3.

Yes; the paragraph there names a precaution that needs to be considered when doing in NSEC walk. I think it should stay, even when NSEC walking is not suggested as a discovery method.

> I think it's still worth a suggestion in the trigger section that
> operators allow AXFR of the signal information. While probing is just
> as fast if there are only a few domains delegated to a NS, there are
> name servers that have hundreds of thousands or millions of delegated
> names.

How about the following, inserted between the 2nd and the 3rd bullet in Section 3.3:

    *  The Parental Agent encounters a Signaling Record during an NSEC
       walk or upon zone transfer of a Signaling Zone;

Thanks,
Peter

-- 
https://desec.io/