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

Paul Wouters <paul@nohats.ca> Tue, 05 March 2019 04:04 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 B8A7B130F08 for <dnsop@ietfa.amsl.com>; Mon, 4 Mar 2019 20:04:34 -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 H94m5Ot82AMN for <dnsop@ietfa.amsl.com>; Mon, 4 Mar 2019 20:04:33 -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 CAAA7130EF2 for <dnsop@ietf.org>; Mon, 4 Mar 2019 20:04:32 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44D3Ds4ml4z25c for <dnsop@ietf.org>; Tue, 5 Mar 2019 05:04:29 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1551758669; bh=I7J6DMqRVA0eCOuUWq2fN78ANFq/cH9tNhD4nwu0Evw=; h=Date:From:To:Subject:In-Reply-To:References; b=p3POWm7geCHgxbcNduBm5XVsN1yQu1o4U5A3ieZ/rx8T31ufWzkEv/UCpHZPf3aTY RCVY+6ag4e8huzApqANIUO/4Eviu70bZQnqN1l6u/v/NtRY5gFEVZ1YjXjqY0Rb3Mq 0GlEvC2O06qBcGSIxXmmVworxRJFu/fkd6e3bvgQ=
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 oitFxaVw4hvT for <dnsop@ietf.org>; Tue, 5 Mar 2019 05:04: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 for <dnsop@ietf.org>; Tue, 5 Mar 2019 05:04:27 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 0F14F5E4BA8; Mon, 4 Mar 2019 23:04:27 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 0F14F5E4BA8
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 019B9411601E for <dnsop@ietf.org>; Mon, 4 Mar 2019 23:04:26 -0500 (EST)
Date: Mon, 4 Mar 2019 23:04:26 -0500 (EST)
From: Paul Wouters <paul@nohats.ca>
To: dnsop <dnsop@ietf.org>
In-Reply-To: <D22DBFF7-4313-442C-93F2-0BD89BAD0293@icann.org>
Message-ID: <alpine.LRH.2.21.1903042300490.2567@bofh.nohats.ca>
References: <155171606493.5281.3957934874516100450.idtracker@ietfa.amsl.com> <5c3cc3f9-2225-9077-fb9e-0fb940bd1c1b@isc.org> <alpine.LRH.2.21.1903042036460.21142@bofh.nohats.ca> <D22DBFF7-4313-442C-93F2-0BD89BAD0293@icann.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/OICNHXwjj44TVyRJ7XJ77JLr6zc>
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 04:04:35 -0000

On Tue, 5 Mar 2019, Paul Hoffman wrote:

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

We can not facilitate those practises by not giving these practises a
code point ?

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

Well, it seems we have a registry for EDNS code points with
experimental/local code points. So I'm not sure how your
comment relates to this or other WGs?

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

Sure, but facilitating those general purpose meta-camels is also not required action of the WG or implementers.

Paul