Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

Paul Wouters <paul@nohats.ca> Fri, 08 March 2019 17:03 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 4A6381279A2 for <dnsop@ietfa.amsl.com>; Fri, 8 Mar 2019 09:03:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 FaRQ9tAheJSe for <dnsop@ietfa.amsl.com>; Fri, 8 Mar 2019 09:03:34 -0800 (PST)
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 1A90A1279AD for <dnsop@ietf.org>; Fri, 8 Mar 2019 09:03:34 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44GDNK5WW0z38y; Fri, 8 Mar 2019 18:03:29 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1552064609; bh=4+OFNxwEWTCdfQque/IYfts3Is27UcXI46q+F/iwLmA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=p5y437d4ENK0hjKkoDeNQAFAE6YR6VBbbSq6IRqB3ykpwhvUNTouu/NUtr1G0Ixrp N7Lb6n0ghcVJ1jCi0AasJzF4zIeWQ/sjzX2gAvC1pXADEu7wAbaakjR4ELwRaLECCw 59t9dTS2Cls/zneD5I4nAoZRxLE8dbqfxt7wQ2jY=
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 vPvPjvcnDBMI; Fri, 8 Mar 2019 18:03:28 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 8 Mar 2019 18:03:28 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8A95F5C856; Fri, 8 Mar 2019 12:03:27 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 8A95F5C856
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 829FC411602B; Fri, 8 Mar 2019 12:03:27 -0500 (EST)
Date: Fri, 8 Mar 2019 12:03:27 -0500 (EST)
From: Paul Wouters <paul@nohats.ca>
To: Ray Bellis <ray@bellis.me.uk>
cc: dnsop@ietf.org
In-Reply-To: <e07b94d6-d974-4e4f-5519-a90cc0e98979@bellis.me.uk>
Message-ID: <alpine.LRH.2.21.1903081154310.30421@bofh.nohats.ca>
References: <155171606493.5281.3957934874516100450.idtracker@ietfa.amsl.com> <5c3cc3f9-2225-9077-fb9e-0fb940bd1c1b@isc.org> <yblef7mp7io.fsf@wu.hardakers.net> <CAKW6Ri5doXL=uBpEy3Eqrkoyfu9rvt9upH9qxXkzZKUgS_=dMw@mail.gmail.com> <ybla7iap5nx.fsf@wu.hardakers.net> <B137690E-8063-4416-BFE2-706F0589AD5F@isc.org> <yblsgw125x4.fsf@w7.hardakers.net> <40758bbd-5289-8e21-8043-3c3d09c6b8d1@nic.cz> <bd27789a-e6f8-adca-874f-a4c298f0891f@bellis.me.uk> <alpine.LRH.2.21.1903072249100.7137@bofh.nohats.ca> <5f06e2ad-3710-4dbf-3c04-ca31f8b19c4a@bellis.me.uk> <alpine.LRH.2.21.1903080916520.20997@bofh.nohats.ca> <e07b94d6-d974-4e4f-5519-a90cc0e98979@bellis.me.uk>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/S_TwtIDEjO6mCtaCQx1PhDJvgEc>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-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, 08 Mar 2019 17:03:36 -0000

On Fri, 8 Mar 2019, Ray Bellis wrote:

[my last email in this thread. I don't think we are progressing and I'd
  like to give others a chance to participate in this thread. But feel
  free to reply]

>>  But assigned and left completely opague is not really suitable for
>>  "heterogenous off-the-shelf software". These different vendors must
>>  understand the meaning of the opaque data even if their functionality
>>  can be non-standard.
>
> No, it does *not* require that at all.

Unless the implementations just log these numbers, they are expected to
do or trigger something. Either with their own interpretation, or by
some helper process or configuration magic interpreting these things for them.

> We very careful referred to the *operators* of the software in the draft, not 
> the implementors.

That's just talking around the issue. You expect bind or knot or unbound
or a DNS load balancer to cause an act to happen based on these
transmitted values.

> The intention is that software operators can define rules in their 
> configuration files such that *they* determine which values have what 
> meaning.

And my argument has been that this is bad DNS design not enhancing
interoperability, and that you should just more narrowly define the
actual things you are trying to do instead of bitbanging them into
opaque data. That way, interoperable RFCs and software can be written.

> In the load-balancer case, they might decide to use a few bits to select one 
> of several RPZ feeds, or perhaps a view, without having to pass the client IP 
> for the use a "source match" ACL to the backend.

> They might decide to use another bit to indicate that the client is trusted 
> such that the server doesn't need to apply RRL.

Specify seperate options and drafts for those use cases. It is better
for the entire community.

> Granted this will need some form of representation in whatever configuration 
> syntax is in use, but that would be implementation dependent.   The minimal 
> implementation would just need to be able to test "tag & mask == value".

This is the wrong way of getting independent implementations to interoperate.

Additionally, as you pointed out yourself, opague data can be abused
for nefarious purposes wile still claiming protocol compliance. By
narrowly specifying things, abusing those values at least forces those
implementations to violate the DNS protocol.

Paul