Re: [ietf-privacy] Fwd: draft-huitema-dnssd-privacy-01.txt

"Christian Huitema" <huitema@huitema.net> Thu, 23 June 2016 18:51 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: ietf-privacy@ietfa.amsl.com
Delivered-To: ietf-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA36912D63E for <ietf-privacy@ietfa.amsl.com>; Thu, 23 Jun 2016 11:51:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable 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 oswkYNscAAb9 for <ietf-privacy@ietfa.amsl.com>; Thu, 23 Jun 2016 11:51:58 -0700 (PDT)
Received: from xsmtp02.mail2web.com (xsmtp02.mail2web.com [168.144.250.215]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 988D412D65E for <ietf-privacy@ietf.org>; Thu, 23 Jun 2016 11:51:58 -0700 (PDT)
Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1bG9jH-00049s-TF for ietf-privacy@ietf.org; Thu, 23 Jun 2016 14:51:57 -0400
Received: (qmail 27231 invoked from network); 23 Jun 2016 18:51:54 -0000
Received: from unknown (HELO huitema2) (Authenticated-user:_huitema@huitema.net@[131.107.160.201]) (envelope-sender <huitema@huitema.net>) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for <dnssd@ietf.org>; 23 Jun 2016 18:51:54 -0000
From: Christian Huitema <huitema@huitema.net>
To: 'S Moonesamy' <sm+ietf@elandsys.com>, 'Tim Chown' <Tim.Chown@jisc.ac.uk>
References: <DM2PR0301MB0655DA3D2AA9FD4FF08E5CA4A8500@DM2PR0301MB0655.namprd03.prod.outlook.com> <FC54AE01-0E03-4414-809E-5A5460F2FCFF@jisc.ac.uk> <6.2.5.6.2.20160623020221.0b6b9df0@resistor.net>
In-Reply-To: <6.2.5.6.2.20160623020221.0b6b9df0@resistor.net>
Date: Thu, 23 Jun 2016 11:51:52 -0700
Message-ID: <001501d1cd80$4f885de0$ee9919a0$@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQF4CwMzLPfj2ndSRfVTW988tEw+yAFsu5GZAWyjbx6glB1+MA==
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-privacy/QBi2N6vDizd2xZYuvZyI7iXhVvw>
X-Mailman-Approved-At: Thu, 23 Jun 2016 11:54:24 -0700
Cc: dnssd@ietf.org, 'Ralph Droms' <rdroms.ietf@gmail.com>
Subject: Re: [ietf-privacy] Fwd: draft-huitema-dnssd-privacy-01.txt
X-BeenThere: ietf-privacy@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Internet Privacy Discussion List <ietf-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-privacy>, <mailto:ietf-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-privacy/>
List-Post: <mailto:ietf-privacy@ietf.org>
List-Help: <mailto:ietf-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-privacy>, <mailto:ietf-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jun 2016 18:52:00 -0000

(Moving this conversation to DNS-SD mailing list)

On Thursday, June 23, 2016 2:53 AM, S Moonesamy wrote:
> 
> Hi Tim,
> At 05:18 22-06-2016, Tim Chown wrote:
> >We're encouraging discussion of privacy considerations in the WG. As a
> >result, we now have a draft (see below), including an initial proposal
> >for a solution, for which we'd welcome wider review. The draft also
> >addresses mDNS/DNS-SD privacy within single subnet scenarios.
> 
> One of the privacy issue identified in the draft (Section 2.4) is device
> fingerprinting.  In Section 3.1, it is proposed to solve the privacy
issues
> described in Section 2.1 by obfuscating instance names.  If I had to pick
one
> privacy threat for that I would choose "correlation".  Obfuscating service
names
> would not address that.

Section 3 describes an initial design that was then abandoned. I guess that
in the next revision we could just remove that section entirely.

On the other hand, the proposal was indeed to use different obfuscated names
at different locations.


> If I understood the draft correctly, the solution "to prevent tracking
over time
> and location, different string values would be used at different
locations, or at
> different times".  QR-codes are used to generate a shared secret and
establish
> trust between two or more "friends".

The private discovery service relies on pre-existing pairings. The pairing
solutions are only drafted in very vague terms in the draft. I really wonder
whether we should go define a complete pairing protocol. Is that in-charter
for DNS-SD? What about competing with existing solutions over Bluetooth,
Wi-Fi, and certainly many more?

-- Christian Huitema