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

Ray Bellis <ray@bellis.me.uk> Tue, 05 March 2019 08:04 UTC

Return-Path: <ray@bellis.me.uk>
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 7798E130E2B for <dnsop@ietfa.amsl.com>; Tue, 5 Mar 2019 00:04:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=portfast.net
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 YRLTCglQ6sig for <dnsop@ietfa.amsl.com>; Tue, 5 Mar 2019 00:04:19 -0800 (PST)
Received: from mail.portfast.net (mail.portfast.net [IPv6:2a03:9800:20:1::2]) (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 9E45612958B for <dnsop@ietf.org>; Tue, 5 Mar 2019 00:04:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=portfast.net; s=dkim; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=KtuMQgYmLGU2K9bz3ODOgvhXs5+WtvuTJPCwKr98OBo=; b=GylCNDoWBft5Cc6mHPSL2S0yjg FUxHQgwSErDru6TUB2FPLKS8Gy6PN+H/OJ/XH6/lrerQqkB8XRwIayI3An9VDZXh2w59wjhZj/1h9 bRYnmY91YmvHOyFpkrrL8Y/mjfcoKgKYIpA1r6vflJqrUvCJrG7ThKQqBTVoHAjLNZTQ=;
Received: from [88.212.170.147] (port=64610 helo=Rays-MacBook-Pro.local) by mail.portfast.net ([188.246.200.9]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1h153g-0000C3-O3 (Exim 4.89) for dnsop@ietf.org (return-path <ray@bellis.me.uk>); Tue, 05 Mar 2019 08:04:16 +0000
To: dnsop@ietf.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>
From: Ray Bellis <ray@bellis.me.uk>
Message-ID: <7cb2ec00-096e-ca03-3328-254552256a32@bellis.me.uk>
Date: Tue, 5 Mar 2019 08:04:16 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <alpine.LRH.2.21.1903042036460.21142@bofh.nohats.ca>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/lVgl1FWMc6HK0CGU8XKrVfAMKT4>
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 08:04:24 -0000


On 05/03/2019 01:44, Paul Wouters 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.

This is why the specification limits the data to a mere 16 bits.

Granted that this might permit more fine-grained "finger printing" when 
combined with other meta data but the intention is that _by itself_ it's 
insufficient to carry any PII (at least not unless your total number of 
clients is < 2^16).

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

It's not a feature, it's a bug.  These internal experiments almost never 
see the light of day, and as a result are unsupportable in e.g. BIND, 
instead relying on internal patches (which are fragile) or bespoke 
implementations (that are often protocol non-conformant).

Meanwhile we have customers who would like to deploy some kind of packet 
tagging but find that the only "blessed" option that kinda fits their 
needs is EDNS Client Subnet.   No thanks!

Ray