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

Paul Wouters <paul@nohats.ca> Thu, 12 August 2021 14:57 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 517EE3A15DB; Thu, 12 Aug 2021 07:57:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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] 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 u_zyIzT3EiNr; Thu, 12 Aug 2021 07:57:24 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 3B54B3A15CC; Thu, 12 Aug 2021 07:57:20 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4GlqXs3TTzzFHH; Thu, 12 Aug 2021 16:57:17 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1628780237; bh=hDWB8rY8KNEB6+1A5Njipspfv0juZWsnbgcKn36Z+7g=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=SYooZ5Jp+YO04pIZ5PYnobAQG8F++XtfAKFnbsKWudlgFYB8cWxuqcSLoSWuHPizw rUk+7cmGnw07QrVSHqTEhTKjK7hi08l9zjxjzdyuxl6CTzm0GQd8nZ5jk9Eruv0PyZ CBJjziaVeaegqucgFNQekRcbxfM3/S/sWPcA0BNA=
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 HJDkhyh_jLdS; Thu, 12 Aug 2021 16:57:16 +0200 (CEST)
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; Thu, 12 Aug 2021 16:57:15 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id B3E6ADDFAD; Thu, 12 Aug 2021 10:57:14 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B0090DDFAC; Thu, 12 Aug 2021 10:57:14 -0400 (EDT)
Date: Thu, 12 Aug 2021 10:57:14 -0400
From: Paul Wouters <paul@nohats.ca>
To: Olafur Gudmundsson <ogud@ogud.com>
cc: Tim WIcinski <tjw.ietf@gmail.com>, dnsop <dnsop@ietf.org>, dnsop-chairs <dnsop-chairs@ietf.org>
In-Reply-To: <AC30D523-B9EA-4E1B-B8A3-85098FAA70A4@ogud.com>
Message-ID: <7216daac-3446-3481-a358-d1b11c92a2d@nohats.ca>
References: <CADyWQ+Fyi1M56t6WQ=0EB1yZf1tKP7uSiaZHLLtvDLn_KUHrng@mail.gmail.com> <AC30D523-B9EA-4E1B-B8A3-85098FAA70A4@ogud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-15"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/BxF6Z0xYyKJEVvikMRZTyB-Uuxs>
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:57:40 -0000

On Thu, 12 Aug 2021, Olafur Gudmundsson wrote:

> 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. 

Not the only one, as you point out below. It is also useful for "vanity algorithms" :)

> 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. 

This would have been excellent to do when we did DS. It would still be
good to do this now, I agree. But it would be too late for some of the
things discussed now. If people insist that we need a parent side
"encrypted transport" indicator, that can be deployed next week, then
the options are DS or NS. By blocking DS use, we are just going to get
a less secure version stuffed in NS. So why I agree in principle with
you, I disagree in practise.

> 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.

It seems inevitable that we will see a few of these, whether we like it
or not. The alternative is that DNSSEC as a whole is disregarded by
some nation states. We don't want those ciphers to go through Standard
Track all the time. So the policy change to me seems reasonable.

> 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. 

In an ideal world yes. In reality we can't stop some of this from
happening.

> 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. 

The "no good reason" is the subjective part of course :)

> 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. 

This is a real concern. I personally do not have the knowledge to say
how much they might derail things or not. Again, it is more of a TLD
policy item then a technical issue. From a technical point of view,
the parent doing a "dumb copy" would be best. But then comes the
lawyers.

Paul