Re: [dnssd] Next steps for privacy discovery

[Daniel Kaiser <[e-mail]>]

Summarizing, the differences between our privacy draft and the new
privacy draft are:

(1)  keys derived from shared secrets    vs     keys derived from
asymmetric keys
(2)  hints (using predictable nonces)      vs     trial decryptions
(3)  backwards compatibility                  vs     defining new RRs


My question is: Why do we need another privacy draft?
The new draft also uses our two-stage approach, meaning first
discovering paired peers and then engaging in direct discovery with them.
Issue (1) already came up during past meetings; as soon as we have
consensus, we can go ahead and adapt our draft accordingly.
Regarding issue (2) nobody opposed when we suggested using hints instead
of trial decryptions for performance reasons. We could assess this issue
again.
I also like the idea Bob Bradley pointed out: sending a predictable
nonce in the client PTR query to allow for suppressing unnecessary messages.
This is similar to our direct query method, which also reduces the
number of sent messages (we should discuss this as well).
We should try to get consensus on (3) tomorrow; if defining new RRs is
the preferred way, we could merge that part into our draft.

Further, in past meetings there has been discussion as to whether we
should switch to a one-stage approach supporting a per-app model, or
stick with our two-stage approach.
We could also support both, which I would prefer, modeling the second
stage of the two-stage approach as a service of
a "DNS server app" that is discoverable via a privacy preserving
one-stage solution.

Also, I wanted to ask if the new draft is meant for DNS-SD/mDNS
exclusively or also for DNS-SD/DNS.
I think, the protocol should not be called Bonjour, because Bonjour is
the name of a concrete implementation of DNS-SD/mDNS.


Kind regards,
Daniel Kaiser


-- 

Dr. Daniel Kaiser
Research Associate
SnT- Interdisciplinary Centre for Security, Reliability and Trust

University of Luxembourg
Maison du Nombre (MNO)
6, avenue de la Fonte
L-4364 Esch-sur-Alzette
Office: E02 0225-010




On 11/04/2018 02:55 AM, Christian Huitema wrote:
>
> On 10/26/2018 11:57 PM, Bob Bradley wrote:
>> 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.
> I do like the reduction in number of queries caused by "trial
> decryption". As you point out the CPU cost could be mitigated by adding
> a predictable nonce to the client queries, with the "proof" part of the
> nonce computed by hashing the client's public key.
>
> The idea of sending queries signed by the client is indeed sound, as it
> enables servers to only respond to authorized clients. But it requires
> that servers process queries in real time, and that's not compatible
> with the "server based" mode of DNSSD, in which application servers
> prepare responses in advance and store them in records published by the
> DNS servers. So the decision boils down to how much compatibility we
> want to retain with the "server based" more of operation.
>
> -- Christian Huitema
>
> _______________________________________________
> dnssd mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnssd