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

Paul Hoffman <> Tue, 05 March 2019 01:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C0976130E66 for <>; Mon, 4 Mar 2019 17:54:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wkYm9Wqnfcmk for <>; Mon, 4 Mar 2019 17:54:35 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 568FB130E68 for <>; Mon, 4 Mar 2019 17:54:35 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 4 Mar 2019 17:54:33 -0800
Received: from ([]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([]) with mapi id 15.00.1367.000; Mon, 4 Mar 2019 17:54:33 -0800
From: Paul Hoffman <>
To: Paul Wouters <>
Thread-Topic: [Ext] [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
Thread-Index: AQHU0vZgvOd4hUlrG0e7ba211pFtag==
Date: Tue, 5 Mar 2019 01:54:32 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [DNSOP] [Ext] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 05 Mar 2019 01:54:38 -0000

On Mar 4, 2019, at 5:44 PM, Paul Wouters <> wrote:
> 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.

As the draft says, they can already do this now with unassigned EDNS0 code points. There is nothing you can do about it.

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

Or a bug. IETF WGs cannot agree on which it is. Some WGs cannot remember which they prefer from year-to-year.

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

That's a fine preference, but it does not align with the reality that anyone can already do that. Not having a standard doesn't prevent abuse.

--Paul Hoffman