Re: [dnssd] Next steps for privacy discovery

Daniel Kaiser <daniel.kaiser@uni-konstanz.de> Wed, 07 November 2018 16:00 UTC

Return-Path: <daniel.kaiser@uni-konstanz.de>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3769D130DC8 for <dnssd@ietfa.amsl.com>; Wed, 7 Nov 2018 08:00:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzW4xqto0UHT for <dnssd@ietfa.amsl.com>; Wed, 7 Nov 2018 08:00:33 -0800 (PST)
Received: from tasso.uni-konstanz.de (tasso.uni-konstanz.de [134.34.240.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB3751274D0 for <dnssd@ietf.org>; Wed, 7 Nov 2018 08:00:32 -0800 (PST)
Received: from lyrae.kim.uni-konstanz.de (lyrae.kim.uni-konstanz.de [134.34.240.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tasso.uni-konstanz.de (Postfix) with ESMTPS id 42qrjV4zM9zpm; Wed, 7 Nov 2018 17:00:30 +0100 (CET)
Received: from [192.168.1.12] (unknown [87.240.243.50]) by lyrae.kim.uni-konstanz.de (Postfix) with ESMTPSA id 9197D117A01C7; Wed, 7 Nov 2018 17:00:30 +0100 (CET)
References: <48bc4612-018e-7aac-6492-05657c466313@huitema.net> <28F9784B-6243-453E-8926-A4EA039217C9@apple.com> <bd86e271-2cb8-e3c1-8a2b-7b6ad1b07363@huitema.net>
From: Daniel Kaiser <daniel.kaiser@uni-konstanz.de>
To: "dnssd@ietf.org" <dnssd@ietf.org>
Cc: Christian Huitema <huitema@huitema.net>
Message-ID: <618389df-c34e-5ffd-f157-98dff7876746@uni-konstanz.de>
Date: Wed, 7 Nov 2018 17:00:30 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <bd86e271-2cb8-e3c1-8a2b-7b6ad1b07363@huitema.net>
Content-Type: multipart/mixed; boundary="------------8B3AAD7DC83BF840CD8D8D3B"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/0HOqG7xc1cAWD4a-DK5jL6U6VU0>
Subject: Re: [dnssd] Next steps for privacy discovery
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Nov 2018 16:00:36 -0000

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
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd