Re: [DNSOP] Input from DNSOP on NCAP proposal

Ben Schwartz <bemasc@google.com> Thu, 26 May 2022 14:31 UTC

Return-Path: <bemasc@google.com>
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 96240C180A7C for <dnsop@ietfa.amsl.com>; Thu, 26 May 2022 07:31:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -22.6
X-Spam-Level:
X-Spam-Status: No, score=-22.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 YBXY0X92gDgW for <dnsop@ietfa.amsl.com>; Thu, 26 May 2022 07:31:13 -0700 (PDT)
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC72FC1850EA for <dnsop@ietf.org>; Thu, 26 May 2022 07:30:55 -0700 (PDT)
Received: by mail-wr1-x436.google.com with SMTP id z15so2357705wrg.11 for <dnsop@ietf.org>; Thu, 26 May 2022 07:30:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6nU51a8XCLK4moQ+gQg7BK80NmXz0faaPnCr+hSPcfg=; b=ngsRGEBXVZfmgkHSS07TTn4c3olq0p6Nk+5qL4r3ZpLo40eJB4uWhLnKugkRsb2R7A M97dmMcQBzAHFhx7BKm9LkI0jzD+Iu6ogu6xBl8dzEewHNrnhZ/HDZTgpuHGvBM8w6VK UOy98KzRXj9WbejsfoOy2h6PtwVdnwNCIJojHQSf5mYMVgDYbuk54RTM//2jtDXQnvMA DzK+IzSO1cX/K4Y1xDDkSnjay0WsQ4P4kmqIUMWsMeMiQzsxxzMtvTrZpmCfbuJKz7yS 5ZrNGMWrc2NCHxQVKpIw/AEAuVVeSse05jXfMupMX8xwLGErDcC5aeItqrD0bV/ieyPm NAMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6nU51a8XCLK4moQ+gQg7BK80NmXz0faaPnCr+hSPcfg=; b=nHGmee8rgq1eM/w2Pl9R1e+JRGh/Z69mSUmn8D2fyRgiCv9IS4mOu8ACnFZzrw/BSl I1tZIKLd5fxXqSxaJZfc+dbz7ITk5q4hUb7OllzlIYxMMal6z+EdEv+d/zYDfW/5n32G xXQUBtyjCj6QL58Jai0ho7O170KJHWgjIkg1CzaeyBQ+6UpNTfhmcpRU6krjqIS2BPEv 8unjL/5gvM0B7oVELZoDeongdlh42b6kRxG+2fxYEYv46Exu/ImzoiSf/eFzh9SuQXtY ZKFHQNSqHjMuAaTA3striwT1prnL9FgTQ96MOLdU59N2pwc8pZFgwRXX2WsV0KqpycfA MtPg==
X-Gm-Message-State: AOAM53393p5FbPg55GYuyPIK/FPvv3orj+jw1a+YKb2H/NJYkpgT/6Xx 8bZ/wIEHaIhI7JGqhOBtTxH6nqo4J+AN+KNUIrAHT9IJ0GB2Vw==
X-Google-Smtp-Source: ABdhPJxjHGsY7emPOETd97F8NHrgEHvzSbgDYnixE0FRhnbTI2x17Lxo7Wfa+yLHiUWjz61bxbqWykzlEQc+k6jMi7c=
X-Received: by 2002:a5d:4b8b:0:b0:20c:f8c5:b9bc with SMTP id b11-20020a5d4b8b000000b0020cf8c5b9bcmr32764888wrt.282.1653575453306; Thu, 26 May 2022 07:30:53 -0700 (PDT)
MIME-Version: 1.0
References: <63C24D03-1E35-44FF-A611-89A5FBFB9569@verisign.com>
In-Reply-To: <63C24D03-1E35-44FF-A611-89A5FBFB9569@verisign.com>
From: Ben Schwartz <bemasc@google.com>
Date: Thu, 26 May 2022 10:30:41 -0400
Message-ID: <CAHbrMsCZW3R4gB8zw=djok93OybUkipZ2MCT01xe1suv6LJGJA@mail.gmail.com>
To: "Thomas, Matthew" <mthomas=40verisign.com@dmarc.ietf.org>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000885d6a05dfeb09d6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/zD9wsKrwjQKzVjbmfy_bSZTJXyw>
Subject: Re: [DNSOP] Input from DNSOP on NCAP proposal
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.34
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: Thu, 26 May 2022 14:31:13 -0000

On Thu, May 26, 2022 at 8:00 AM Thomas, Matthew <mthomas=
40verisign.com@dmarc.ietf.org> wrote:
...

> The proposal would involve delegating a candidate TLD.
>

I'm not familiar with the proposal, so I'm just trying to understand the
context.  Is the proposal to do this for _every_ candidate TLD?  Or just
one candidate TLD?  Or somewhere in between?


> The TLD would not be DNSSEC signed.
>

Why not?  It seems fine for it to be signed, so long as the signature
expires before the TLD goes live.

Configuration 3: Use a properly configured empty zone with correct NS and
> SOA records. Queries for the single label TLD would return a NOERROR and
> NODATA response.
>
>
This seems safest and easiest (no need for custom server software!).  Is
there a reason not to do it this way?