[dnssd] Next steps for privacy discovery

Christian Huitema <huitema@huitema.net> Fri, 26 October 2018 07:08 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 D55CA127AC2 for <dnssd@ietfa.amsl.com>; Fri, 26 Oct 2018 00:08:51 -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 uVOdugiE5Kvc for <dnssd@ietfa.amsl.com>; Fri, 26 Oct 2018 00:08:49 -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 7D902128CFD for <dnssd@ietf.org>; Fri, 26 Oct 2018 00:08:49 -0700 (PDT)
Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx18.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1gFwEe-0003hJ-KS for dnssd@ietf.org; Fri, 26 Oct 2018 09:08:46 +0200
Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1gFwEV-0007Ga-8X for dnssd@ietf.org; Fri, 26 Oct 2018 03:08:39 -0400
Received: (qmail 4979 invoked from network); 26 Oct 2018 07:08:32 -0000
Received: from unknown (HELO [172.16.33.227]) (Authenticated-user:_huitema@huitema.net@[217.16.13.130]) (envelope-sender <huitema@huitema.net>) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for <dnssd@ietf.org>; 26 Oct 2018 07:08:31 -0000
To: dnssd <dnssd@ietf.org>
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: <48bc4612-018e-7aac-6492-05657c466313@huitema.net>
Date: Fri, 26 Oct 2018 09:08:25 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Originating-IP: 168.144.250.234
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.47)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5m4DAVcvzNRyfnASbsuZto1602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzXMPpKBnlzcICbdbWbUSKtVjyn5UrUp4n4yKOOaq9Ax0H2emL9OFLzzzHmk+tWpaVDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5XXP/PhacSgLwLXdxYAFaWE5EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhiSGt4Ko2sv7hY6P0Yu3OA+AIcPc2JG++Fh0y/kogNkMJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+X2XX9bIs GDSYq5OAASmskVIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2DHXeua4usuyudZl7ZJWmg 5a0jiD6XqsJZtjQxlyCdsezqWtkpJGM3LlmFs5AdkE6VbBF60t09JPqYDV9lpEWTlrrS9EUFbOHH te+8JJ1uQ3Vk354Leo8WHhg9Xcph2esmZk4AVtnYApSiFQp1w3dnUoiPn/2xNqt6sQVacVXeY6AU 1zqm/evfkH8cHl25+qKdzoZJbv2GES9fRTEUwtaGCR2vWOKTBJk2Pbgs7SLYxsB09WmAGZznescg 91X6BuEZeHkJ3RppXwEO+1/ngUOKuHG5BnVj6tDKYf18xfK0O5ipahgr6AgAfpld1xYSvcj+w6nI oDr0sXUZ7YZoZ/GZ+rQ53ngkwHVnz6S3TKYH8fH6vvsamCqhsCKWQTQWW5aiOYN2LGYOY+RZZ70I EJvMPP9qwM7RXpJS8RjTdyh2j5BSM6Vge5/tyLofFHTUZzjpzRBCCyVCnQKBwcrUTMoPTDRj9D8H LKHAKpPGP8EPnuBvlPE9yn4+7R7hw716lUpV
X-Report-Abuse-To: spam@quarantine6.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/Gwa9LwBVjLZWsccOmim4d3fhURA>
Subject: [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: Fri, 26 Oct 2018 07:08:52 -0000

With some prodding from David and Barbara, I resubmitted the DNSSD
Privacy and Pairing drafts before the Bangkok meeting. The changes are:

* For both drafts, add reference to the privacy requirement draft and to
the scaling draft,

* For both drafts, add a short paragraph in the intro stating that
things might change based on the scaling analysis,

* For the privacy draft, remove the requirement analysis part and
replace it by a reference to the requirement draft.

David is prodding me to write a complete revision of the privacy draft,
using the "shared public key" approach, which has very good scaling
capabilities and reasonably robust resilience to attacks. It is a bit
different from the draft that Bob Bradley sent, and I will comment on that
later. I could not submitted a revised discovery proposal before the dead
line, but here are the broad lines of what I would do: 

1) Server has a public key, which is "somewhat secret" -- it is only
provided to authorized clients and they are expected to keep it secret.

2) Single announcement per server of the form nonce|proof, where the
nonce is a "predictable nonce" computed as a hash of quantized time and
secret public key.

3) Clients do a search for the nonce, just like in the current spec, but
there is only one nonce per server, so the client will get exactly one
response.

4) If we kept the current "two phase" structure, use a TLS protocol
extension to demonstrate knowledge of the server's public key in the
client hello. I think we can build on the work done for SNI encryption,
which would fit quite well.

5) We may consider having a different nonce for each available service,
e.g. have the announcement computed as hash of quantized time, service
type and secret public key. This would allow for a single phase solution.

6) We may also have the service name used as a proof, e.g. encoding of
nonce and service name with the server's private key.

7) We need to say something about protecting the service connections
from clients to server. DNSSD privacy would not be that much useful if
the clear text data on the service connection revealed the identity of
client or server. I think a combination of SNI encryption and TLS 1.3
would work, but that may be extra work.

8) We also need to recommend randomized host names for the A/AAAA
records of the servers, otherwise there is also a big leak.

Some of the complexity in the DNSSD approach comes from a desire to fit
into the existing DNSSD formats. This leads to some tricks like Base64
encoding of nonce, time stamps and proofs so they fit in existing
fields like service type or instance name. Bob's draft jettisons DNSSD
compatibility and defines a new binary format. That is definitely
cleaner, but there is a trade-off: a new protocol implies that we cannot
reuse the DNSSD server infrastructure. It would be interesting to gauge
the WG consensus on that tradeoff.

The other big difference between Bob's draft and the evolving proposal
is the use of trial decryption. In Bob's approach, clients send probes
that the server tries to decrypt by using the public keys of various
registered peers or friends. This has scaling issues similar to the
pairwise keys that we relied on in our first drafts. After discussions,
we grew very concerned with these scaling issues and the
corresponding potential for DOS attacks. We instead evolved towards
a system of "predictable nonces".

The predictable nonces are a tradeoff between privacy and performance.
Predictable nonces can be precomputed by the server, which reduces the
processing cost and also limits the potential of DOS attacks. But then,
all authorized clients of a server can generate the same predictable
nonces, and thus all authorized clients can detect the presence
of other authorized clients. This reduces privacy somewhat, although not
necessarily by a whole lot. All authorized clients can discover the server,
and thus retrieve its IP address. Network level analysis can then reveal
which clients are also connecting to that server. This means that the information
potentially leaked by the predictable nonce is also available at a lower
layer. I think that the trade-off is thus between a minor privacy leak and
a significant performance gain, but of course other WG members may have a
different analysis. It would be interesting to gauge WG consensus on that
subject.

Looking forward to the debates in Bangkok!

-- Christian Huitema
 






 -- Christian Huitema