Subject: [dnssd] Next steps for privacy discovery

From: Christian Huitema <[email-masked]>
Date: Fri, 26 Oct 2018 09:08:25 +0200

With some prodding from David and Barbara, I resubmitted the DNSSD
Privacy and Pairing drafts before the Bangkok meeting. The changes are:

* For both drafts, add reference to the privacy requirement draft and to
the scaling draft,

* For both drafts, add a short paragraph in the intro stating that
things might change based on the scaling analysis,

* For the privacy draft, remove the requirement analysis part and
replace it by a reference to the requirement draft.

David is prodding me to write a complete revision of the privacy draft,
using the "shared public key" approach, which has very good scaling
capabilities and reasonably robust resilience to attacks. It is a bit
different from the draft that Bob Bradley sent, and I will comment on that
later. I could not submitted a revised discovery proposal before the dead
line, but here are the broad lines of what I would do: 

1) Server has a public key, which is "somewhat secret" -- it is only
provided to authorized clients and they are expected to keep it secret.

2) Single announcement per server of the form nonce|proof, where the
nonce is a "predictable nonce" computed as a hash of quantized time and
secret public key.

3) Clients do a search for the nonce, just like in the current spec, but
there is only one nonce per server, so the client will get exactly one
response.

4) If we kept the current "two phase" structure, use a TLS protocol
extension to demonstrate knowledge of the server's public key in the
client hello. I think we can build on the work done for SNI encryption,
which would fit quite well.

5) We may consider having a different nonce for each available service,
e.g. have the announcement computed as hash of quantized time, service
type and secret public key. This would allow for a single phase solution.

6) We may also have the service name used as a proof, e.g. encoding of
nonce and service name with the server's private key.

7) We need to say something about protecting the service connections
from clients to server. DNSSD privacy would not be that much useful if
the clear text data on the service connection revealed the identity of
client or server. I think a combination of SNI encryption and TLS 1.3
would work, but that may be extra work.

8) We also need to recommend randomized host names for the A/AAAA
records of the servers, otherwise there is also a big leak.

Some of the complexity in the DNSSD approach comes from a desire to fit
into the existing DNSSD formats. This leads to some tricks like Base64
encoding of nonce, time stamps and proofs so they fit in existing
fields like service type or instance name. Bob's draft jettisons DNSSD
compatibility and defines a new binary format. That is definitely
cleaner, but there is a trade-off: a new protocol implies that we cannot
reuse the DNSSD server infrastructure. It would be interesting to gauge
the WG consensus on that tradeoff.

The other big difference between Bob's draft and the evolving proposal
is the use of trial decryption. In Bob's approach, clients send probes
that the server tries to decrypt by using the public keys of various
registered peers or friends. This has scaling issues similar to the
pairwise keys that we relied on in our first drafts. After discussions,
we grew very concerned with these scaling issues and the
corresponding potential for DOS attacks. We instead evolved towards
a system of "predictable nonces".

The predictable nonces are a tradeoff between privacy and performance.
Predictable nonces can be precomputed by the server, which reduces the
processing cost and also limits the potential of DOS attacks. But then,
all authorized clients of a server can generate the same predictable
nonces, and thus all authorized clients can detect the presence
of other authorized clients. This reduces privacy somewhat, although not
necessarily by a whole lot. All authorized clients can discover the server,
and thus retrieve its IP address. Network level analysis can then reveal
which clients are also connecting to that server. This means that the information
potentially leaked by the predictable nonce is also available at a lower
layer. I think that the trade-off is thus between a minor privacy leak and
a significant performance gain, but of course other WG members may have a
different analysis. It would be interesting to gauge WG consensus on that
subject.

Looking forward to the debates in Bangkok!

-- Christian Huitema

 -- Christian Huitema

---

From: Bob Bradley <[email-masked]>
Date: Fri, 26 Oct 2018 09:57:03 -0700

If I understand correctly, a revision to draft-ietf-dnssd-privacy-05 would change it from each server advertising a _pds._tcp service instance for each of its paired peers to advertising a single _pds._tcp service instance for only itself (which sounds like a nice improvement). For that case, I think the scalability comparison between predictable nonces vs trial decryptions would be the cost of filtering additional multicast traffic vs performing additional signature verifications.

Assuming a network with 50 peers and 3 of them I'm paired to, here's my understanding of the work between the two approaches:

Predictable nonces:

When I join the network and start discovery, I announce my own _pds._tcp service instance (hash of time). Each peer would receive it and for each of its paired peers, calculate PrivateInstanceName = <time> | hash( <time> | <peer public key> ) and compare that to the announced name (47 ignore it, 3 cache it). Then send a PTR query for _pds._tcp. Each peer on the network responds with its own _pds._tcp service instance. For each response I receive, calculate a PrivateInstanceName for each of my paired peers and compare each response to my list of PrivateInstanceNames (47 ignored, 3 cached).

Trial decryptions:

When I join the network and start discovery, I announce my availability via a probe (signature of time) . Each would peer would receive it and for each of its paired peers, perform a signature verification (47 ignore it and 3 cache it). The 3 paired peers send a response. When I receive each response, perform a signature verification against each of my paired peers (which should succeed so it caches all 3 responses).

The question seems to be whether the traffic reduction in the trial decryption approach of only needing to respond to paired peers is worth the CPU cost of additional signature verifications.

Another option could be to use the predictable nonce approach, but in the PTR query for _pds._tcp, include an additional record containing the predictable nonce of the querier. The receiver could use this to suppress responses to unpaired peers. This could provide a similar traffic reduction to the trial decryption approach while retaining the CPU optimization of predictable nonces.

> On Oct 26, 2018, at 12:08 AM, Christian Huitema <[email-masked]> wrote:
> 
> _______________________________________________
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd

---

From: Lanlan Pan <[email-masked]>
Date: Sun, 28 Oct 2018 21:48:07 -0400

> which would fit quite well.

I wonder if we could consider about use tls psk (pre-shared key) ?  server
can assign different key to different client.

-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Christian Huitema <[email-masked]>
Date: Mon, 29 Oct 2018 10:20:56 -0700

On 10/28/2018 6:48 PM, Lanlan Pan wrote:
>
>
> Christian Huitema <[email-masked]
> <mailto:[email-masked]>>于2018年10月26日周五 下午3:09写道：
>
>     ...
>
> I wonder if we could consider about use tls psk (pre-shared key) ? 
> server can assign different key to different client.

That's what we were specifying in the current privacy draft. There are
two issues. The first one is that if you use TLS-PSK, the Client Hello
must include a key identifier. If there is a different key for each
client, the key identifier could become a client identifier. We solved
that  by using a "predictable nonce" for key identifier. The second
issue is of course that assigning different keys to different clients
requires extra management at the server, something that is not needed in
the "private public key" class of solutions.

-- Christian Huitema