Re: [dnssd] Next steps for privacy discovery

[Daniel Kaiser <[e-mail]>]

Regarding the trade-off between hinting using predictable nonces and
trial decryptions,
I wanted to add that we could also use a bloomfilter based solution for
reducing the
number of necessary hinting messages while not needing costly trial
decryptions.

I summarized the current state of my idea in the attached markdown document.
If you are interested, I could elaborate on this idea.

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