IETF Logo Mail Archive

Re: [dnssd] I-D Action: draft-huitema-dnssd-privacy-00.txt

Tom Pusateri <pusateri@bangj.com> Thu, 24 March 2016 00:27 UTC

Return-Path: <pusateri@bangj.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5743F12D115 for <dnssd@ietfa.amsl.com>; Wed, 23 Mar 2016 17:27:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-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 DwwOCpSGx-lA for <dnssd@ietfa.amsl.com>; Wed, 23 Mar 2016 17:27:03 -0700 (PDT)
Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B43D128874 for <dnssd@ietf.org>; Wed, 23 Mar 2016 17:27:03 -0700 (PDT)
Received: from [172.16.10.140] (cpe-174-109-142-205.nc.res.rr.com [174.109.142.205]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 5431F1DAB1; Wed, 23 Mar 2016 20:26:09 -0400 (EDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_C083F45E-F06E-467E-877D-0A97E78F56A1"; protocol="application/pgp-signature"; micalg="pgp-sha256"
X-Pgp-Agent: GPGMail 2.6b2
From: Tom Pusateri <pusateri@bangj.com>
In-Reply-To: <620719BD-01B1-426C-8FAC-09C615DFBF7C@istumbler.net>
Date: Wed, 23 Mar 2016 20:27:00 -0400
Message-Id: <B87ACED9-E8EE-4C90-B35F-874910C0C6FA@bangj.com>
References: <20160310013909.9336.65458.idtracker@ietfa.amsl.com> <7E27ED38-3858-4080-A31E-2116EA2DD436@ecs.soton.ac.uk> <EMEW3|53a64596503ce821209d6d873fee625as2GNBl03tjc|ecs.soton.ac.uk|7E27ED38-3858-4080-A31E-2116EA2DD436@ecs.soton.ac.uk> <055301d184bc$11a0e450$34e2acf0$@huitema.net> <620719BD-01B1-426C-8FAC-09C615DFBF7C@istumbler.net>
To: Alf Watt <alf@istumbler.net>
X-Mailer: Apple Mail (2.3124)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnssd/9miKIxpl1_jaigYsgi7NToMTVLI>
Cc: dnssd@ietf.org, Christian Huitema <huitema@huitema.net>
Subject: Re: [dnssd] I-D Action: draft-huitema-dnssd-privacy-00.txt
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Mar 2016 00:27:05 -0000

I was thinking the same thing. There won’t always be a hybrid proxy present but if there is one, it would be the perfect intermediary for unicast TLS connections to each client and service provider.

Tom

> On Mar 23, 2016, at 7:54 PM, Alf Watt <alf@istumbler.net> wrote:
> 
> Just looking over the paper titles for DPRIV it seems like the solution is going to be TLS or DTLS of the DNS server to client connection, which should encapsulate the unicast DNS-SD as well as the usual A and AAAA lookups.
> 
> Is the concern about information disclosure from devices using DNS-SD and mDNS for multicast advertising and discovery?
> 
> Best,
> Alf
> 
>> On Mar 22, 2016, at 9:25 PM, Christian Huitema <huitema@huitema.net> wrote:
>> 
>>> On Thursday, March 17, 2016 4:12 PM, Tim Chown wrote:
>>> 
>>> Hi,
>>> 
>>> Ralph and I would welcome comments to the list on this draft.
>>> 
>>> Tim
>> 
>> Yep. Me too. This draft
>> (https://datatracker.ietf.org/doc/draft-huitema-dnssd-privacy/) is the
>> continuation of the work to minimize metadata disclosure went moving to
>> random locations, and in particular when connecting to Wi-Fi hot spots.
>> 
>> The first big disclosure comes with the MAC address, and can be addressed
>> with MAC address randomization. The next big disclosure are the DHCP
>> messages, which use to disclose things like DNS name of the node, and the
>> DNS traffic, which would happily pass a full log of visited URL to the DNS
>> server chosen by the hot spot manager. The IETF has been working on that
>> with the DHCP anonymity profile, and with the DNS Privacy work in DPRIVE.
>> Which means we have to look at the next big disclosure source, which happens
>> to be DNS-SD.
>> 
>> The draft proposes essentially to obfuscate the names used in DNS-SD so that
>> cooperating parties understand them, but they look like gibberish to casual
>> observers. I am sure that DNS-SD WG members have opinions about that.
>> 
>> -- Christian Huitema
>> 
>> 
>> 
>> _______________________________________________
>> dnssd mailing list
>> dnssd@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnssd
> 
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd

v2.23.0 | Report a Bug | By Email