Re: [dnssd] Next steps for privacy discovery

Christian Huitema <huitema@huitema.net> Sun, 04 November 2018 01:55 UTC

Return-Path: <huitema@huitema.net>
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 2512D12D4E6 for <dnssd@ietfa.amsl.com>; Sat, 3 Nov 2018 18:55:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 nMUmxx9saJx3 for <dnssd@ietfa.amsl.com>; Sat, 3 Nov 2018 18:55:44 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 EE3E5128BCC for <dnssd@ietf.org>; Sat, 3 Nov 2018 18:55:43 -0700 (PDT)
Received: from xsmtp04.mail2web.com ([168.144.250.231]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1gJ7dd-0008JJ-JW for dnssd@ietf.org; Sun, 04 Nov 2018 02:55:42 +0100
Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1gJ7dY-0002Oi-SO for dnssd@ietf.org; Sat, 03 Nov 2018 21:55:37 -0400
Received: (qmail 14392 invoked from network); 4 Nov 2018 01:55:32 -0000
Received: from unknown (HELO [31.133.149.93]) (Authenticated-user:_huitema@huitema.net@[31.133.149.93]) (envelope-sender <huitema@huitema.net>) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for <dnssd@ietf.org>; 4 Nov 2018 01:55:31 -0000
To: dnssd@ietf.org
References: <48bc4612-018e-7aac-6492-05657c466313@huitema.net> <28F9784B-6243-453E-8926-A4EA039217C9@apple.com>
From: Christian Huitema <huitema@huitema.net>
Openpgp: preference=signencrypt
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <bd86e271-2cb8-e3c1-8a2b-7b6ad1b07363@huitema.net>
Date: Sun, 4 Nov 2018 08:55:29 +0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <28F9784B-6243-453E-8926-A4EA039217C9@apple.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Originating-IP: 168.144.250.231
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.32)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5iYr/1f9DhKXKEeud1fu/w5602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzXMPpKBnlzcICbdbWbUSKtVjyn5UrUp4n4yKOOaq9AxsUJvgTFbE6bpcsiQLR68qVDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5gla7yk9cQlpQyisTE3JepE5EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxh1SJjtqxg9ToQOYgvpTXfiGuWFHL2CFALT37iujGyMC2K4cpU ualkQCN89mFr4hzV9Toz96geSJlwqLmXoHr6lp7KuHNaaKdg7iBEZefdsNV4YIf5ImMTjwbMKp8Y PS53nf7PGnOpecYaJDTU+UZIqwmLmW5xejNwBYllkh0bdnaMr5g51/dlPiU31fwEOKxqkVWClPVv bW5lVyQanRxw5nX9q2g89emBxjk4vbSaEK4mBBZyuzyr5ZxdVdkNxbnSdADg25CDX78caB9Pgj1m GtOITDa6LxNU+V0EKPyMEBNyxTnaYDGrcFhcWdN8WJ/kojmX5u6QQ8A3tr7Vu+yOdzuUcUw82oJH NumIeSk+phZG047RODDSOAU8VRBdjarRhquvBzKEzdsRbaiLpp7t87ZNvhN3LQlcXUm7c+4sJSS4 E4wEuUnsmRe7F3MGeyJeF38+1Ld/o5jGCpWO7tD53Zo5mMl7zU5iUyA2L29tUc1gy7a4XBIVNwIx j/+TVqdzhN6k/jWdd5JAUDIoPsO/pO/BYTkEOOb1RnEQ4ngzvGbLm0j/4xGRSH4jmGjWq+Sp9R/2 gMGq0KWAzmMf+ibVDrD2Ztt6Q8YW92VRrLWLRLx3Cau2PfsL3/JUcd0arQH0qgmimWMOaQfKKyR3 R8Z5yFss+n2ffnQxt6aJ7klZab+hIGHWVnRxW2VRSAIC84Y0TCFzbdHp875yVjNUvaMOXYpado7U VGYebUJcnJQ5nNwxL7hrJSk60SF3F6RYOYr2
X-Report-Abuse-To: spam@quarantine9.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/kneh_x0GR3ehPpGF_C24p6QL7tw>
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: Sun, 04 Nov 2018 01:55:46 -0000


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