Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

revised section 2.1; minor updates in other parts #2

Merged
merged 1 commit into from
May 22, 2016
Merged

revised section 2.1; minor updates in other parts #2

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
88 changes: 43 additions & 45 deletions draft-huitema-dnssd-privacy.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -113,14 +113,13 @@ solutions are discussed in <xref target="KW14a" />
and <xref target="KW14b" />.
</t>
<t>
There are cases when nodes connected
to a network want to provide
There are cases when nodes connected to a network want to provide
or consume services without exposing their identity to the other
parties connected to the same network. Consider for example a
traveller wanting to upload pictures from a phone to a laptop
traveler wanting to upload pictures from a phone to a laptop
when connected to the Wi-Fi network of an Internet cafe, or
two travellers who want to share files between their laptops
when waiting for their plane in an airport lounge.
two travelers who want to share files between their laptops
when waiting for their plane in an airport lounge.
</t>
<t>
We expect that these exchanges will start with a discovery
Expand All @@ -130,9 +129,9 @@ or a file store in our examples. The user of the other device will
discover this service, and then connect to it.
</t>
<t>
When analysing these scenarios in <xref target="analysis"/>, we find that
When analyzing these scenarios in <xref target="analysis"/>, we find that
the DNS-SD messages leak identifying information such as instance name,
host name or service properties. We review the design constraint of a solution
host name or service properties. We review the design constraint of a solution
in <xref target="design"/>, and describe the proposed solution in
<xref target="solution"/>.
</t>
Expand All @@ -147,20 +146,20 @@ in <xref target="design"/>, and describe the proposed solution in

<section title="Privacy implications of DNS-SD" anchor="analysis">
<t>
DNS-Based Service Discovery (DNS-SD) is defined in <xref target="RFC6763" />.
It allows nodes to publish the availibility of an instance of a service by
inserting specific records in the DNS (<xref target="RFC1033"/>,
<xref target="RFC1034"/>, <xref target="RFC1035"/>) or by publishing
DNS-Based Service Discovery (DNS-SD) is defined in <xref target="RFC6763" />.
It allows nodes to publish the availability of an instance of a service by
inserting specific records in the DNS (<xref target="RFC1033"/>,
<xref target="RFC1034"/>, <xref target="RFC1035"/>) or by publishing
these records locally using
multicast DNS (MDNS) <xref target="RFC6762"/>. The service availability
will be described in three types of records:
multicast DNS (mDNS) <xref target="RFC6762"/>.
Available services are described using three types of records:
</t>
<t>
<list style="hanging">
<t hangText="PTR Record:">Associate the service name in the domain with
the "instance" name published by the node.
<t hangText="PTR Record:">Associates a service type in the domain with
an "instance" name of this service type.
</t>
<t hangText="SRV Record:">Provides the node name, port number, priority and
<t hangText="SRV Record:">Provides the node name, port number, priority and
weight associated with the service instance, in conformance with <xref target="RFC2782" />.
</t>
<t hangText="TXT Record:">Provides a set of attribute-value pairs describing
Expand All @@ -174,50 +173,49 @@ instance names, node names, service attributes and other data, as well as review
the implications of using the discovery service as a client.
</t>

<section title="Privacy implication of publishing instance names" anchor="instanceLeak" >
<section title="Privacy implication of publishing Service Instance Names" anchor="instanceLeak" >
<t>
In the first phase of discovery, the client will obtain a copy of all
the PTR records associated to a service in a given naming domain. Each
record contains a domain name starting with an instance name.
Instance names are free form description of the instance, and are meant to
convey enough information so discovery clients can easily select the
desired service.
Section 4 of <xref target="RFC6763" /> gives the
following example for the instance names of a printer service:
In the first phase of discovery, the client obtains all
the PTR records associated with a service type in a given naming domain.
Each PTR record contains a Service Instance Name defined in Section 4 of <xref target="RFC6763" />:
</t>
<!--
TODO: address comments from Stuart Cheshire. This example is wrong, it is
a misreading of RFC6763.
-->

<t>
<figure>
<artwork>
Building 2, 1st Floor . example . com .
Building 2, 2nd Floor . example . com .
Building 2, 3rd Floor . example . com .
Building 2, 4th Floor . example . com .
Service Instance Name = &lt;Instance&gt; . &lt;Service&gt; . &lt;Domain&gt;
</artwork>
</figure>
</t>

<t>
Nodes that use DNS-SD in a mobile environment will rely on the specificity
of the instance name to identify the desired service. In our example of users
wanting to upload pictures to a laptop in an Internet Cafe, the list of
available services may look like:
The &lt;Instance&gt; portion of the Service Instance Name is meant to convey
enough information for users of discovery clients to easily select the desired service instance.
Nodes that use DNS-SD over mDNS <xref target="RFC6762" /> in a mobile environment will rely on the specificity
of the instance name to identify the desired service instance.
In our example of users wanting to upload pictures to a laptop in an Internet Cafe, the list of
available service instances may look like:
</t>
<t>
<figure>
<artwork>
Alice's notebook . local .
Bob's laptop . local .
Image store for Carol . local .
Alice's Images . _imageStore._tcp . local
Alice's Mobile Phone . _presence._tcp . local
Alice's Notebook . _presence._tcp . local
Bob's Notebook . _presence._tcp . local
Carol's Notebook . _presence._tcp . local
</artwork>
</figure>
</t>
<t>
Alice will see the list on her phone and understand intuitively that she should
pick the fist item. The discovery will "just work." It will also reveal
to anybody who cares that Alice is currently visiting the Internet Cafe.
pick the fist item. The discovery will "just work".
</t>
<t>
However, DNS-SD/mDNS will reveal to anybody that Alice is currently visiting the Internet Cafe.
It further discloses the fact that she uses two devices, shares an image store, and uses a chat application supporting the
_presence protocol on both of her devices. She might currenty chat with Bob or Carol, as they are also using a _presence supporting chat application.
This information is not just available to devices actively browsing for and offering services, but to anybody passively listing to the network traffic.
</t>
</section>

Expand Down Expand Up @@ -327,7 +325,7 @@ Authorized parties should be able to "de-obfuscate" the names,
while non-authorized third parties will not be. For example,
if both Alice notebook and Bob's laptop use an obfuscation process,
the list of available services should appear differently
to them and to thrid parties. Alice's phone will be able to
to them and to third parties. Alice's phone will be able to
de-obfuscate the name of Alice's notebook, but not that of
Bob's laptop. Bob's phone will do the opposite. Carol will do
neither.
Expand Down Expand Up @@ -508,7 +506,7 @@ These components are detailed in the following subsections.
<t>
Nodes publishing services with DNS-SD and concerned about their privacy MUST
use a randomized host name. The randomized name MUST be changed when
network conectivity changes, to avid the correlation issues described in
network connectivity changes, to avid the correlation issues described in
<xref target="timing" />. The randomized host name MUST be used in
the SRV records describing the service instance, and the corresponding
A or AAAA records MUST be made available through DNS or MDNS, within the
Expand Down Expand Up @@ -559,7 +557,7 @@ and the corresponding records SHOULD be published
in order to meet the requirement defined in <xref target="timing" />.
</t>
<t>
The complete instance name MUST be genrated using the following process:
The complete instance name MUST be generated using the following process:
</t>
<t>
<figure>
Expand Down