IETF Logo Mail Archive

Re: [DNSOP] Call for Adoption: Structured Data for Filtered DNS

Paul Wouters <paul@nohats.ca> Mon, 23 January 2023 15:06 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 E4687C1524A8; Mon, 23 Jan 2023 07:06:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.094
X-Spam-Level:
X-Spam-Status: No, score=-7.094 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ygm8HwSB8vw; Mon, 23 Jan 2023 07:06:26 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::85]) (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 81980C1522CE; Mon, 23 Jan 2023 07:06:26 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4P0tjB6JQFz7Cv; Mon, 23 Jan 2023 16:06:22 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1674486382; bh=jGlePSM4GAGmK7tFi87NXkEtA3R2DaPm8PlSznKyesQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=MsvkvRLDLV6dQ0Wgk+kGgRrOqZxdnZEqZI+LUUTXErxlXuseNxVBoUd6KGPzvMbZV K/mJ+rpSpw5grejdiZcPqA7i3dziqaF6mlkfuXru2CfXN3D5SYxikhA6tUa3JeR5Ho Gr9jfftuyPK6BFwlAvgbYffUsuUU305frbCAenUw=
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 SvAERxllSJh1; Mon, 23 Jan 2023 16:06:21 +0100 (CET)
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; Mon, 23 Jan 2023 16:06:21 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 029B167C30A; Mon, 23 Jan 2023 10:06:20 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id F3CC767C309; Mon, 23 Jan 2023 10:06:20 -0500 (EST)
Date: Mon, 23 Jan 2023 10:06:20 -0500
From: Paul Wouters <paul@nohats.ca>
To: Tim Wicinski <tjw.ietf@gmail.com>
cc: dnsop <dnsop@ietf.org>, dnsop-chairs <dnsop-chairs@ietf.org>
In-Reply-To: <CADyWQ+Fh2d2MwWCFo6dtkPNQfTCE3d5FXvSGrD8S+t7xgRuqtQ@mail.gmail.com>
Message-ID: <aa777f20-d00f-f681-7fa0-2ed9b17f4dad@nohats.ca>
References: <CADyWQ+Fh2d2MwWCFo6dtkPNQfTCE3d5FXvSGrD8S+t7xgRuqtQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Has3l-5RyDxUpXMVQYBtF_TxiKw>
Subject: Re: [DNSOP] Call for Adoption: Structured Data for Filtered DNS
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: Mon, 23 Jan 2023 15:06:31 -0000

On Sun, 22 Jan 2023, Tim Wicinski wrote:

> Subject: [DNSOP] Call for Adoption: Structured Data for Filtered DNS

> This starts a Call for Adoption for draft-wing-dnsop-structured-dns-error-page

I have no objection to adoption. I say this instead of "yes" to adoption
because:

 	A client might choose to display the information in the
 	EXTRA-TEXT field if and only if the encrypted resolver has
 	sufficient reputation, according to some local policy (e.g. user
 	configuration, administrative configuration, or a built-in list
 	of respectable resolvers). This limits the ability of a malicious
 	encrypted resolver to cause harm.

While this limits the risks, it also strongly limits its applicability.
Eg it is mostly useful for wireless carriers and not at all for wifi
hotspots.

I do have a number of other issues with the draft, but those can be discussed
after adoption.

Paul

v2.23.0 | Report a Bug | By Email