Re: [dnssd] New Version Notification for draft-huitema-dnssd-tls-privacy-00.txt

[Bob Bradley <[e-mail]>]

> On Mar 11, 2019, at 12:14 AM, Christian Huitema <[e-mail]> wrote:
> On 3/11/2019 12:03 AM, Bob Bradley wrote:
>>> As designed, the answer is yes, the client would send 20 packets. I
>>> understand very well that there is an alternative design in which the
>>> server sends a packet announcing its arrival, and then every interested
>>> client discovers the server and contacts it. I believe that the scaling
>>> is actually equivalent:
>>> 
>>> 1) In my design's worst case, the client sends N packets, and P servers
>>> who are present perform O(N) trial decryptions. Total O(P.N2).
>>> 
>>> 2) In the server announce design, P arriving servers send P packets upon
>>> arrival on the network, and O(N) clients perform N trial decryptions.
>>> Total O(P.N2) as well.
>> In (1), there are N multicast packets per client and P unicast responses from paired servers. In (2), there is 1 multicast request per client and P unicast from paired servers. Many devices act as both client and server. Multicast vs unicast can make a big difference in the number of packets processed by each device.
>> 
>> As an example, my device has 40 paired devices and the network has about 300 devices browsing for and offering services (by looking at mDNS). If we assume other devices have a similar number of paired devices then:
>> 
>> Approach 1: 12000 multicast requests (and trial decryptions) and 40 unicast responses.
>> Approach 2: 300 multicast requests (and trial decryptions) and 40 unicast responses.
> Using your numbers, there would be 12000 trial decryptions in approach 2 as well. Each client has to try 40 different server keys to see which one would work.
> 
I think it would be 480000 trial decryptions for approach 1 (12000 packets * 40 keys) and 12000 trial decryptions for approach 2 (300 packets * 40 keys).
> But I am not convinced at all that this 40/300 split is something we will see in privacy oriented applications. If we are looking at application pairing rather than device pairing, then the server and client role are very flexible, the ratio of client and server will be close to parity, and the number of pairing per application could be very small.
> 
Yes, my case may be higher than most. I can imagine the number of pairings growing as private, end-to-end communication becomes more prevalent.

The main difference I see between approaches for the server discovery phase is which key is used. Approach 1 encrypts to the server's key. Approach 2 signs with its own key. This difference requires approach 1 to multiply the number of multicast request packets it sends by the number of server keys it has.

Something to consider with approach 1 is using the client's discovery key in the first multicast request packet.This would avoid needing to send multiple multicast packets to discover servers.