Re: [DNSOP] Working Group Last Call for Revised IANA Considerations for DNSSEC

Olafur Gudmundsson <ogud@ogud.com> Thu, 12 August 2021 14:02 UTC

Return-Path: <ogud@ogud.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 656F03A4233; Thu, 12 Aug 2021 07:02:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 hcMwQCfnY2uz; Thu, 12 Aug 2021 07:02:40 -0700 (PDT)
Received: from smtp84.iad3b.emailsrvr.com (smtp84.iad3b.emailsrvr.com [146.20.161.84]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D58683A421C; Thu, 12 Aug 2021 07:02:39 -0700 (PDT)
X-Auth-ID: ogud@ogud.com
Received: by smtp19.relay.iad3b.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id D8BE440124; Thu, 12 Aug 2021 10:02:38 -0400 (EDT)
From: Olafur Gudmundsson <ogud@ogud.com>
Message-Id: <AC30D523-B9EA-4E1B-B8A3-85098FAA70A4@ogud.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_39498C51-2B67-4144-ACFA-B1363A449A06"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Thu, 12 Aug 2021 10:02:38 -0400
In-Reply-To: <CADyWQ+Fyi1M56t6WQ=0EB1yZf1tKP7uSiaZHLLtvDLn_KUHrng@mail.gmail.com>
Cc: dnsop <dnsop@ietf.org>, dnsop-chairs <dnsop-chairs@ietf.org>
To: Tim WIcinski <tjw.ietf@gmail.com>
References: <CADyWQ+Fyi1M56t6WQ=0EB1yZf1tKP7uSiaZHLLtvDLn_KUHrng@mail.gmail.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Classification-ID: 6d05449f-ff25-47bc-a67a-9eafbaff3945-1-1
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/z9CLggirapSABCXfgYHgGtNWm8Y>
Subject: Re: [DNSOP] Working Group Last Call for Revised IANA Considerations for DNSSEC
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: Thu, 12 Aug 2021 14:02:55 -0000


> On Aug 4, 2021, at 11:29 AM, Tim Wicinski <tjw.ietf@gmail.com> wrote:
> 
> 
> All
> 
> This starts a Working Group Last Call for draft-ietf-dnsop-dnssec-iana-cons
> 
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-iana-cons/ <https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-iana-cons/>
> 
> The Current Intended Status of this document is: Standards Track
> 
> Please review the draft and offer relevant comments.
> If this does not seem appropriate please speak out. 
> If someone feels the document is *not* ready for publication, please speak out with your reasons.
> 
> This starts a two week Working Group Last Call process, and ends on:  18 August 2021
> 
> thanks
> tim


Hi Tim, 

I read the draft and I oppose it on principle, it is a bad idea. 
 
IMHO the ONLY benefit of it is to encourage DS record overloading with random data that has no DNSSEC relevance,  leading to abuse that threatens to turn the DS record into the new TXT overloading record resulting in large DS sets. 

The DS record is a unique record that it lives only at the parent side of delegation, when DNS was defined no such records were envisioned, if more are needed this working should take up a new work item to 
define a sub-set of the RRtype number space as Parent side-only to have a proper debate on the topic. 

Further more this draft  makes it trivial for vanity algorithms to be added to the DS and DNSKEY registries threatening the depletion of the small number space. 
There is a big difference between registration and deployment, only algorithms that the IETF thinks have a benefit to the whole community and have a expectation of wide deployment should be registered. 
Those of us who have fought the battles to get new algorithms rolled out and supported by large fraction of the internet can attest that increasing the number of supported algorithms is a no-win battle as it may lead to fragmented validation on the internet, forcing zones to sign with multiple algorithms ==> increasing packet size for no good reason. 

Getting DS records into parents at TLD level is hard, CDS/CDNSKEY are supposed to make that easier but uptake has been slow due resistance by industry and any overloading of the DS record may derail it. 

Olafur