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

Bob Bradley <> Mon, 11 March 2019 15:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C12B128B01 for <>; Mon, 11 Mar 2019 08:33:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0Oi8xYcV0sjl for <>; Mon, 11 Mar 2019 08:33:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 15B8A124B0C for <>; Mon, 11 Mar 2019 08:33:58 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id x2BFVWtH043814; Mon, 11 Mar 2019 08:33:50 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version : content-type : sender : from : message-id : subject : date : in-reply-to : cc : to : references; s=20180706; bh=kGNDrJwylrZXqeZ9Gx+TojBcr2nZUqnbsGYgfkhjEG4=; b=oEKFAWXVklTALGUgO/W3/usnnHNMJHgUxfhkWusKcQGeBZz9bZLjysw5UmA1iVSBRPWj YGmIpvGi7EmFGrSY5O8W6X0+FeZDeoHbLcnK0Hlcju6JHUSDbDgFjYAvFiu2OJs29eGE bMcIJ2i4C6+dbm334a11bkUtXZed0Z9qvHMnFBIsr7epA49zsKoVZD317fdQ7Dq6L/8X COhSuBHmUiltmc5k0ohaPA2ccRVygoH6DWFmO7O5JfGUef+i/X3mUonEXltPsHYgDiUn MzAdluTU5ELMHACLUSFAQkA8am8V/Os2en5VKrBfn/NnIozr54Tq3lZbqismmONN2r77 eQ==
Received: from ( []) by with ESMTP id 2r4da7fhsx-8 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 11 Mar 2019 08:33:49 -0700
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_N+6ydIKIqlgSKt3SOCaqKw)"
Received: from ( []) by (Oracle Communications Messaging Server 64bit (built Oct 24 2018)) with ESMTPS id <>; Mon, 11 Mar 2019 08:33:47 -0700 (PDT)
Received: from by (Oracle Communications Messaging Server 64bit (built Oct 24 2018)) id <>; Mon, 11 Mar 2019 08:33:46 -0700 (PDT)
X-Va-T-CD: 058bbac8ca772bcfc9e38720b87faa94
X-Va-E-CD: 73fd81e39f7123add50a9943e2d3e256
X-Va-R-CD: 38097f5f91ac0986f9cb12414439efcc
X-Va-CD: 0
X-Va-ID: f4b3927a-eee9-49d2-a794-9e05db807845
X-V-T-CD: 058bbac8ca772bcfc9e38720b87faa94
X-V-E-CD: 73fd81e39f7123add50a9943e2d3e256
X-V-R-CD: 38097f5f91ac0986f9cb12414439efcc
X-V-CD: 0
X-V-ID: fd2f1ef7-99a2-411a-bf61-d12f08f70807
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-03-11_12:,, signatures=0
Received: from [] by (Oracle Communications Messaging Server 64bit (built Oct 24 2018)) with ESMTPSA id <>; Mon, 11 Mar 2019 08:33:46 -0700 (PDT)
From: Bob Bradley <>
Message-id: <>
Date: Mon, 11 Mar 2019 08:33:43 -0700
In-reply-to: <>
Cc: dnssd <>
To: Christian Huitema <>
References: <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.2)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-11_12:, , signatures=0
Archived-At: <>
Subject: Re: [dnssd] New Version Notification for draft-huitema-dnssd-tls-privacy-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Mar 2019 15:34:00 -0000

> On Mar 11, 2019, at 12:14 AM, Christian Huitema <> 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.