Subject: [dnssd] DNSSD privacy scaling issues

From: Christian Huitema <[email-masked]>
Date: Sun, 14 Jan 2018 14:55:27 -1000

We want privacy. That means that the devices will "offer service to some
subset of clients", rather than "offer to everybody". But we do not
delegate privacy to the infrastructure, so we cannot have solutions in
which the infrastructure performs access control. That leaves solution
in which the service is "offered to everybody", but only qualified
clients understand the "real name" behind the obfuscated name. Hence the
general structure: service announces an obfuscated name, typically
function of time and secret. Clients will find the available services on
the network, and filter out those that they are not interested in.

There are two options for the trust token: symmetric key, or asymmetric.

In the symmetric version, client and server manage a shared secret. Both
client and server can construct the obfuscated name. Server publishes a
name, encrypt or hash of time-based nonce with shared key. Clients can
also construct a priori the obfuscated names of the servers that they
are interested in. Client retrieves all names and check whether some of
them match the expected peer list. Or, in server based discovery, client
asks server whether obfuscated name is published. The problem there is a
tradeoff between scalability and impersonation. If we use the same
shared secret for all clients, the protocol scales well, but any
authorized client can impersonate the server for all other clients. If
we use pairwise secrets, as specified in the current draft, clients
cannot impersonate the server for other clients but the protocol
complexity increases significantly.

In the asymmetric version, client knows the public key of the server.
Server constructs the obfuscated instance name by encrypting the a
time-based nonce with the private key. Client looks at all available
obfuscated names, and attempts to decrypt every available name. This
does not scale very well - public key operation times number of keys
known to client times number of services present. But...

In the asymmetric version, server could also construct an obfuscated
service name by encrypting a time-based nonce with the public key.
Client can also construct the obfuscated service name, because it knows
the public key. It can look for that name, and normally only finds one
instance of the server. It can verify that this is the right server by
decrypting the obfuscated name. So we get a privacy respecting discovery
system in which the server publishes exactly one record, and the client
typically accesses exactly one record per service/server that it discovers.

---

From: Christian Huitema <[email-masked]>
Date: Sun, 14 Jan 2018 15:08:07 -1000

> typically accesses exactly one record per service/server that it discovers.

In the asymmetric key version, privacy depends on the public key being
secret. If it is not, anybody can attempt to decrypt the obfuscated name
published by the servers, and check whether the result matches the
expected time-based nonce -- we get a "nonce-oracle". Adversaries can
collect lists of public keys, and use the oracle to track which servers
are advertising on a given network.

Treating the public key as a shared secret between the server and
authorized clients does significantly simplify the protocol:
"authorization to discover" simply means access to the public key. As we
saw above, we can use a nonce encrypted with the public key (or hashed
with the public key) as a service identifier. Maybe add the actual
service name in the mix if several services are managed using the same
public key.

Note that using the same key for all clients does not diminish privacy
compared to a solution that uses just bilateral secrets. The real secret
is the identity, presence and location of the server, and that secret
can be discovered by any authorized client. If just one client is
compromised, the server privacy is compromised, and having separate
secrets for each client won't change that.

-- Christian Huitema