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

Joseph Lorenzo Hall <> Wed, 22 June 2016 14:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D6FB512D8F8 for <>; Wed, 22 Jun 2016 07:44:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 40t3nj2AJ9tK for <>; Wed, 22 Jun 2016 07:44:16 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 024A212D5A0 for <>; Wed, 22 Jun 2016 07:39:34 -0700 (PDT)
Received: by with SMTP id j2so64669623vkg.2 for <>; Wed, 22 Jun 2016 07:39:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=N+zIhCn/C6RkvU1+pvvTSqP6AaiNi/Z8cANODzvJGS0=; b=FPX16nkuy/jt3ge+TCxXSH0YhP7FCN4sK2lctaDY114h1lC4SKXGqP+ht4xWCjbg+H ptJSIf8U6ylHdsbMJitQp1j+NMuRYWf9kpYndSPvV8ghhOMl6lsqaJ6OzXebtVpZHlyn WESHBe49Jj2j5hHCvmFuS0TJiAKGBHHbzmo9g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=N+zIhCn/C6RkvU1+pvvTSqP6AaiNi/Z8cANODzvJGS0=; b=asGMqW74Lyvt3BxbftqtTeygu0qxFPMn6TTg9Q+G380qNjF0BQCQ/yO307Clkn0kyh WmHfTdOHr+HgYfS9zhrj7U6ZhyY3Mp2GPmuu4DAliQc0fKF23LOTNaA0WPEXb9+qqWL6 Zx/5gvfWViQm9c1lGX1yb7K2PN2aU8X6Z7TFIr+pSZtUSi+rbD4KrcycZDiMqbMff4c5 JZGcfPhUQWKAINwZxnGdVkZc0lCwA/7sLuu7bkwieMYEd5IzW4cLicw9ahekqp0muveX cqWroL9ItnMz7tN+qqP8rkvjxd7iRFcZvTj8Pt22KaTYQ7QLHWc9KjGX3rFT3aeaGEJv mIHA==
X-Gm-Message-State: ALyK8tJfmfN9UQtH7dgZIyGz1FkgWNlJwc9ydCX3rpx6CoLzQgG+rweGGMJmL5CXStKz6ZI+x2Q45OwAae+YM4Yb
X-Received: by with SMTP id 66mr12035903uat.146.1466606373699; Wed, 22 Jun 2016 07:39:33 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 22 Jun 2016 07:39:14 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Joseph Lorenzo Hall <>
Date: Wed, 22 Jun 2016 10:39:14 -0400
Message-ID: <>
To: Tim Chown <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "" <>, Christian Huitema <>, Ralph Droms <>
Subject: Re: [ietf-privacy] Fwd: draft-huitema-dnssd-privacy-01.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Internet Privacy Discussion List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Jun 2016 14:44:19 -0000

Thanks for this. Some comments:

* The last paragraph in Section 2.4 seems to be making the inevitable
"what can we really do about fingerprinting?" argument. It would be
great if you could acknowledge that despite the severe technical and
practical limits on combatting fingerprinting, specifications should
try their best to keep that surface area to a minimum. That may be too
normative for this document? (Although, of course, it's clear you care
about that!). As a pointer the w3c TAG had a great set of findings on
unsanctioned tracking that included the following on fingerprinting:
"because combatting fingerprinting is difficult, new Web
specifications should take reasonable measures to avoid adding
unneeded fingerprinting surface area. However, added surface area
should not be a primary factor in determining whether to add a new

* In 4.1.1 it says, "Strictly speaking, displaying and scanning
QR-codes does not establish a secure private channel, as others could
also photograph this code; but it is reasonable secure for the
application area of private service discovery." Is this not a threat
model from your two more casual use cases stated in the document? That
is, if we change the use case to two activists/journalists in Syria at
a cafe, would you choose a different design. (For example, have the
service generate a short random code since that will be QR-ified
anyway.) I recognize this is just one possible option here from the
document and that others (like WoT PKI) might be more appropriate for
my Syria example.

On Wed, Jun 22, 2016 at 8:18 AM, Tim Chown <> wrote:
> Hi,
> In the dnssd WG, we are developing methods to enable scalable DNS-based
> service discovery, which in practice means enabling mDNS/DNS-SD to work over
> multiple links within a site. As defined, mDNS/DNS-SD are link-local
> protocols, not forwarded by routers. If successful, one ‘win’ is that users
> with devices can discover services that may be physically near them, but
> that lie in a different subnet.
> At a high level, the proposed solution works by clients/resolvers sending
> queries to hybrid proxies running on specific subnets (which may be manually
> configured in an enterprise scenario, or auto-discovered in an unmanaged
> home network scenario), which then issue local service discovery messages,
> the answers to which are relayed back to the originating querier.
> 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.
> Feel free to comment here, or join the dnssd WG list and contribute there.
> Many thanks,
> Tim & Ralph, dnssd WG co-chairs
> Begin forwarded message:
> From: Christian Huitema <>
> Subject: [dnssd] FW: New Version Notification for
> draft-huitema-dnssd-privacy-01.txt
> Date: 10 June 2016 at 21:02:50 BST
> To: "" <>
> Cc: Daniel Kaiser <>
> Here is a new version of the "DNS-SD Privacy" draft. I co-authored it with
> Daniel Kaiser. Daniel is completing his PhD at the University of Konstanz,
> in Germany, studying issues related to privacy and discovery. This new draft
> is in my opinion much improved from the version 00 that I presented in
> Buenos Aires. You can read the abstract below for the broad lines of the
> proposed solution. Or, better yet, read the draft and comment!
> -- Christian Huitema
> -----Original Message-----
> From: []
> Sent: Friday, June 10, 2016 12:35 PM
> To: Christian Huitema <>; Daniel Kaiser
> <>
> Subject: New Version Notification for draft-huitema-dnssd-privacy-01.txt
> A new version of I-D, draft-huitema-dnssd-privacy-01.txt
> has been successfully submitted by Christian Huitema and posted to the IETF
> repository.
> Name: draft-huitema-dnssd-privacy
> Revision: 01
> Title: Privacy Extensions for DNS-SD
> Document date: 2016-06-10
> Group: Individual Submission
> Pages: 26
> URL:
> Status:
> Htmlized:
> Diff:
> Abstract:
>   DNS-SD allows discovery of services published in DNS or MDNS.  The
>   publication normally discloses information about the device
>   publishing the services.  There are use cases where devices want to
>   communicate without disclosing their identity, for example two mobile
>   devices visiting the same hotspot.
>   We propose to solve this problem by a two-stage approach.  In the
>   first stage, hosts discover Private Discovery Service Instances via
>   DNS-SD using special formats to protect their privacy.  These service
>   instances correspond to Private Discovery Servers running on peers.
>   In the second stage, hosts directly query these Private Discovery
>   Servers via DNS-SD over TLS.  A pairwise shared secret necessary to
>   establish these connections is only known to hosts authorized by a
>   pairing system.
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> The IETF Secretariat
> _______________________________________________
> dnssd mailing list
> _______________________________________________
> ietf-privacy mailing list

Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology []
1401 K ST NW STE 200, Washington DC 20005-3497
e:, p: 202.407.8825, pgp:
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871