Subject: [dnssd] WGLC on draft-ietf-dnssd-privacy-01

From: Tim Chown <[email-masked]>
Date: Mon, 19 Jun 2017 14:24:36 +0000

Dear dnssd WG participants,

We are initiating a WG Last Call today on draft-ietf-dnssd-privacy-01, as can be found at https://tools.ietf.org/html/draft-ietf-dnssd-privacy-01

The call will close on Friday 7th July, giving us a week to review the outcome ahead of the Prague meeting.

Please send any comments, including indications of support for progression of the document as is, to the [email-masked] list.

We intend to open a WGLC on the related pairing draft soon (draft-ietf-dnssd-pairing-01), but we believe an update will be published first. 

Abstract

   DNS-SD (DNS Service Discovery) normally discloses information about
   both the devices offering services and the devices requesting
   services.  This information includes host names, network parameters,
   and possibly a further description of the corresponding service
   instance.  Especially when mobile devices engage in DNS Service
   Discovery over Multicast DNS at a public hotspot, a serious privacy
   problem arises.

   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.

Thanks,

Ralph and Tim
dnssd WG co-chairs

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 25 Jun 2017 23:07:10 +0200

On Mon, Jun 19, 2017 at 02:24:36PM +0000,
 Tim Chown <[email-masked]> wrote 
 a message of 38 lines which said:

> We are initiating a WG Last Call today on
> draft-ietf-dnssd-privacy-01, as can be found at
> https://tools.ietf.org/html/draft-ietf-dnssd-privacy-01

Read it and it seems OK to me. But I see one technical weakness, and
two things that I find puzzling.

In section 3.2.2, if I understand correctly the proposal for a
predictable nonce, it seems to me it has a weakness: end-users
machines do not always have proper clock synchronisation (see also 5.5
which mentions it, for an unrelated issue). True, taking only the
first 24 bits of the time will help (some machines with different
clocks will nevertheless end in the same time interval), but it is not
sufficient if bad luck makes two machines fall in different intervals.

In section 2.4 "There is however an argument that devices providing
services can be discovered by observing the local traffic" Another
weakness of this argument is not mentioned: mDNS is multicasted so
anyone can listen, eve on a switched network. Local traffic isn't.

In section 3.4, "Host names are typically not visible by the users,
and randomizing host names will probably not cause much usability
issues." Is it always true? It seems to me several discovery protocols
(over Bluetooth for instance) display the host name to the end user.

---

From: Christian Huitema <[email-masked]>
Date: Mon, 26 Jun 2017 07:18:19 -0700

> two things that I find puzzling.
Thanks for the review.

> sufficient if bad luck makes two machines fall in different intervals.
True. The solution requires that the participating devices have "good
enough" clocks -- to the minute, in practice. It is clearly a trade off
between usability and performance, and also resistance to DOS. The
initial design had unconstrained nonce instead. The problem with
unconstrained nonce is that they cannot be pre-computed by the peer,
which open the possibility of a DOS attack: creates many nonces, and
force the peer to compute as many hashes. Besides, nonces have a
weakness too -- end-user machines do not always have proper sources of
randomness.

So in practice we require end users machines to have some sense of time.
Maybe we should be more upfront about that.

> anyone can listen, eve on a switched network. Local traffic isn't.
Good point. Will fix that text.
> (over Bluetooth for instance) display the host name to the end user.
In DNS-SD, host names are not meant to be visible. The UI examples all
use the instance name.

We did consider something like an aliasing system for host names. Once
devices have recognized each other, they could "decrypt" the host name,
so applications could use it directly.

Any suggestion?

-- Christian Huitema

---

From: Daniel Kaiser <[email-masked]>
Date: Mon, 26 Jun 2017 17:15:46 +0200

Thank you very much for the review.

Regarding the host names, I described a solution for privacy-preserving
host name resolution via mDNS in my thesis.
Summarizing, it works as follows (assuming Alice wants to resolve Bob's
host name):

• Bob offers a PTR and a SRV resource record for his _pds service
instance, and an A
resource record associated with his randomized mDNS name, e.g.
“AB1234EF.local”.
• Upon receiving Bob’s PTR resource record, Alice processes the hint
contained in the
service instance name and learns that it is Bob’s service instance.
• Alice resolves this service instance retrieving the corresponding SRV
resource record.
She then resolves the randomized hostname, “AB1234EF.local”, obtaining
Bob’s A
resource record.
• The daemon on Alice’s device updates the local DNS cache, and creates
a CNAME
record, establishing “AB1234EF.local” as a canonical name for
“bob.privacy.local”.
• Applications on Alice’s device can now simply use something like
gethostbyname("bob.privacy.local")  for resolving Bob’s private host name.

This name (or just the "bob" part of it) could then also be displayed it
in a UI...
But as Christian Huitema said, the GUI typically only shows instance names,
which is not influenced by our solution.

Should we add such a way of pirvacy-preserving host name resolution to
the draft?
We are currently working on a 02 version.

kind regards
Daniel

On 06/26/2017 04:18 PM, Christian Huitema wrote:
> _______________________________________________
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 26 Jun 2017 20:41:07 +0200

On Mon, Jun 26, 2017 at 07:18:19AM -0700,
 Christian Huitema <[email-masked]> wrote 
 a message of 58 lines which said:

> The solution requires that the participating devices have "good
> enough" clocks

Which, IMHO, should be written in the RFC.

> -- to the minute, in practice.

It is not sufficient. The current text says "We will thus use this 24
bit number as nonce, represented as 3 octets." If two machines have
almost perfectly synched clocks, one being at 20:35:44 today, and the
other at 20:35:43, the values won't have the same first 24 bits
(1011001010100010101010000000000 vs. 1011001010100010101001111111111).

There is no obvious solution. We cannot have "fuzzy" comparisons with
nonces.

---

From: Daniel Kaiser <[email-masked]>
Date: Mon, 26 Jun 2017 22:47:47 +0200

Yes. But still, it is obvious that these nonces represent adjacent time
intervals.

10110010101000101010011 + 1 = 10110010101000101010100

When receiving a nonce that does not match a host's current timestamp,
the host has to check whether the received nonce represents an adjacent
time interval.
If so, the host  should accept the previous interval if the current
interval is less than half over,
and the next interval otherwise.
We could also just accept the surrounding intervals; its a compromise
between the replay window and the time skew tolerance.

Nevertheless, we should definitely clarify this in the draft. Thank you :).
In our specification, we forgot to mention the carry.

kind regards
Daniel

---

From: Christian Huitema <[email-masked]>
Date: Mon, 26 Jun 2017 16:07:22 -0700

> There is no obvious solution. We cannot have "fuzzy" comparisons with
In fact there is a solution, which I implemented in my tests. Given a
clock precision X, the device knows that its real clock could be
somewhere between T-X and T+X. There are a finite number of time stamps
in that interval, and it should be ready to accept them all. Or query
them all, if it is doing polling.

-- Christian Huitema