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

Paul Wouters <paul@nohats.ca> Tue, 05 March 2019 01:45 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 6A927130E5E for <dnsop@ietfa.amsl.com>; Mon, 4 Mar 2019 17:45:05 -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 uwQ1Ks8p3LUw for <dnsop@ietfa.amsl.com>; Mon, 4 Mar 2019 17:45:03 -0800 (PST)
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 03733130E2F for <dnsop@ietf.org>; Mon, 4 Mar 2019 17:45:03 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44D07w1Kntz9h; Tue, 5 Mar 2019 02:45:00 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1551750300; bh=nwXrSUGmIjIcK2/J66vr0ex9NXmX7A8P7iqaFQVw1Pg=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=hSE2wEfWWD1E2s9eBgzI7DOLNG/DqJh2O1/s6umMa/OTri3vYvFv6S/qdC/ooCZlP q1ypHk1n8uM9lbiUxcHXj4k4UT/Bc1aM47MqdYmJ69bHwgsp/pmMyRn8LhQ/rM2/fw Wg/0G1RawQ3lBPMNvyAFlw9RWak5P74ogZMwfMOA=
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 jrKo5XTZmnPV; Tue, 5 Mar 2019 02:44:58 +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; Tue, 5 Mar 2019 02:44:57 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id D65605E4BA8; Mon, 4 Mar 2019 20:44:56 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca D65605E4BA8
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CD2FB411601E; Mon, 4 Mar 2019 20:44:56 -0500 (EST)
Date: Mon, 4 Mar 2019 20:44:56 -0500 (EST)
From: Paul Wouters <paul@nohats.ca>
To: Ray Bellis <ray@isc.org>
cc: dnsop@ietf.org
In-Reply-To: <5c3cc3f9-2225-9077-fb9e-0fb940bd1c1b@isc.org>
Message-ID: <alpine.LRH.2.21.1903042036460.21142@bofh.nohats.ca>
References: <155171606493.5281.3957934874516100450.idtracker@ietfa.amsl.com> <5c3cc3f9-2225-9077-fb9e-0fb940bd1c1b@isc.org>
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/ejINk8Gz0Egdm0ibMkVp7bsaZNg>
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: Tue, 05 Mar 2019 01:45:06 -0000

On Mon, 4 Mar 2019, Ray Bellis wrote:

> This new draft describes a way for clients and servers to exchange a limited 
> amount of information where the semantics of that information are completely 
> unspecified, and therefore determined by bi-lateral agreement between the 
> client and server operators.

This makes me very nervous. An edge ISP DNS server could use this to
mark DNS packets from certain users, and applications could use this as
another cookie to track users, especially in light of endusers talking
directly to open resolvers like the Quads, from within the application,
bypassing the operating system.

> There are known cases where bespoke implementations are using experimental 
> EDNS option values for this purpose, for example for a front-end 
> load-balancer to tell the server whether an incoming connection arrived over 
> TCP or UDP (c.f. my XPF draft).

Great. And once experimenting is done, submit a draft and get a real
EDNS code point. Do this as many times as you want. The idea of a
limited experimental space is that you cannot rely on it to be rolled
out into the wild word. That's a feature.

> A goal of this draft is to assign a common EDNS code-point such that popular 
> OSS implementations can support similar features interoperably.

I would much rather see 10 specfic EDNS code points for features, than a
kitchen sink EDNS option that can be abused to send potentially
dangerous tracking identifiers that we cannot distinguish from actual
DNS infrastructure options.

Paul