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

Paul Hoffman <paul.hoffman@icann.org> Tue, 05 March 2019 01:54 UTC

Return-Path: <paul.hoffman@icann.org>
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 C0976130E66 for <dnsop@ietfa.amsl.com>; Mon, 4 Mar 2019 17:54:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkYm9Wqnfcmk for <dnsop@ietfa.amsl.com>; Mon, 4 Mar 2019 17:54:35 -0800 (PST)
Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 568FB130E68 for <dnsop@ietf.org>; Mon, 4 Mar 2019 17:54:35 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 4 Mar 2019 17:54:33 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1367.000; Mon, 4 Mar 2019 17:54:33 -0800
From: Paul Hoffman <paul.hoffman@icann.org>
To: Paul Wouters <paul@nohats.ca>
CC: IETF DNSOP WG <dnsop@ietf.org>
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: <D22DBFF7-4313-442C-93F2-0BD89BAD0293@icann.org>
References: <155171606493.5281.3957934874516100450.idtracker@ietfa.amsl.com> <5c3cc3f9-2225-9077-fb9e-0fb940bd1c1b@isc.org> <alpine.LRH.2.21.1903042036460.21142@bofh.nohats.ca>
In-Reply-To: <alpine.LRH.2.21.1903042036460.21142@bofh.nohats.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <E4605AA57DE3644D84C6F69894813ABD@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/JUi9o-5qFg05wG5yRWdmWiE0Apw>
Subject: Re: [DNSOP] [Ext] 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:54:38 -0000

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