Re: [DNSOP] [Fwd: New Version Notification for draft-peetterr-dnsop-parent-side-auth-types-00.txt]

Paul Wouters <paul@nohats.ca> Fri, 25 September 2020 02:53 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 31E9D3A0E8C for <dnsop@ietfa.amsl.com>; Thu, 24 Sep 2020 19:53:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, URIBL_BLOCKED=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 qRquqWbFgkW9 for <dnsop@ietfa.amsl.com>; Thu, 24 Sep 2020 19:53:22 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::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 72F723A0E83 for <dnsop@ietf.org>; Thu, 24 Sep 2020 19:53:22 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4ByGgh4f0KzlS; Fri, 25 Sep 2020 04:53:20 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1601002400; bh=YfB4LgG5AQcJauh8Vc7//BuGzwoIofr8DgkkrkxsK8s=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=OBoYZnEFOMp38wEKLWHvo64rfUqUj05imGI2fyoyzD4U7CutuHxk/vfG23t94nJmB seZEUfKhOzVJOy6H8tE6G6IXmo/Jxh2R6iPLXUKo7sUdAZtQ3HDplH6JBzduY2wccL VxmUYqxOQ6tBsReUxQIZiqJFp4EavYMxb6jNkM5E=
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 jfq4OXY64CdE; Fri, 25 Sep 2020 04:53:19 +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; Fri, 25 Sep 2020 04:53:19 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 569C56029BA2; Thu, 24 Sep 2020 22:53:17 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4E43666AF7; Thu, 24 Sep 2020 22:53:17 -0400 (EDT)
Date: Thu, 24 Sep 2020 22:53:17 -0400
From: Paul Wouters <paul@nohats.ca>
To: Peter van Dijk <peter.van.dijk@powerdns.com>
cc: dnsop <dnsop@ietf.org>, hrpc@irtf.org
In-Reply-To: <702a5de3ddcef844aeb80b4c071ee9559aaac650.camel@powerdns.com>
Message-ID: <alpine.LRH.2.23.451.2009242244031.1610064@bofh.nohats.ca>
References: <160096974346.12277.16853345396397035889@ietfa.amsl.com> <702a5de3ddcef844aeb80b4c071ee9559aaac650.camel@powerdns.com>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/8LDGlpQPmzLGQMbqL2G1jlzDEM0>
Subject: Re: [DNSOP] [Fwd: New Version Notification for draft-peetterr-dnsop-parent-side-auth-types-00.txt]
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: Fri, 25 Sep 2020 02:53:24 -0000

[added hrpc to CC: list]

On Thu, 24 Sep 2020, Peter van Dijk wrote:

> When talking to Petr Spacek about this, he came up with the following:
> -if-, long enough ago, besides DS, a range of RRtype numbers would have
> been reserved with the same processing rules, i.e. these types live in
> the -parent- and not on the -child-, then both DSPKI and NS2T could
> become parent side records through the simple act of requesting an
> IANA allocation from that special range.

That is an incredibly dangerous idea. It is basically a wildcard from
the parent to make claims about the child, that the child cannot
control. You can imagine many kind of RRTYPEs that be be used, eg:

ADULT_CONTENT
POLITICAL_SPEECH
GOVERNMENT_BLOCKED
MONITOR_USERS
GEOGRAPHIC_CONSTRAINT

Of course, governments can already dictate that ISPs do any of these
things, but with this proposal you are giving them an awesome censorship
tool. And anyone not complying to the RFCs implementing these, could be
in clear violation of the working of the internet and should be punished.

Letting the parent make arbitrary statements about the DNS child is too
dangerous a tool to roll out.

Partially this can be mitigated by making the registry Internet Standard
Required, but that would put a lot of pressure on IETF and DNSOP later
on - pressure that is not technical in nature, but political.

I understand the desire for "if we need the parent to say something
about the child in the future, we would already have the infrastructure
running". Indeed, it is a neat idea. But too dangerous.

Paul

> Name:           draft-peetterr-dnsop-parent-side-auth-types
> Revision:       00
> Title:          Parent-side authoritative DNS records for enhanced delegation
> Document date:  2020-09-24
> Group:          Individual Submission
> Pages:          5
> URL:            https://www.ietf.org/id/draft-peetterr-dnsop-parent-side-auth-types-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-peetterr-dnsop-parent-side-auth-types/
> Html:           https://www.ietf.org/id/draft-peetterr-dnsop-parent-side-auth-types-00.html
> Htmlized:       https://tools.ietf.org/html/draft-peetterr-dnsop-parent-side-auth-types-00