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

Christian Huitema <huitema@huitema.net> Mon, 11 March 2019 18:06 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 5B1521277D8 for <dnssd@ietfa.amsl.com>; Mon, 11 Mar 2019 11:06:17 -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=unavailable 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 voLtm_xXzB9e for <dnssd@ietfa.amsl.com>; Mon, 11 Mar 2019 11:06:16 -0700 (PDT)
Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 01C21124BF6 for <dnssd@ietf.org>; Mon, 11 Mar 2019 11:06:16 -0700 (PDT)
Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx65.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1h3PJQ-000BE8-B9 for dnssd@ietf.org; Mon, 11 Mar 2019 19:06:13 +0100
Received: from [10.5.2.12] (helo=xmail02.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 1h3PJE-0003rk-HT for dnssd@ietf.org; Mon, 11 Mar 2019 14:05:57 -0400
Received: (qmail 23744 invoked from network); 11 Mar 2019 18:05:42 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.166]) (envelope-sender <huitema@huitema.net>) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for <dnssd@ietf.org>; 11 Mar 2019 18:05:42 -0000
To: Bob Bradley <bradley=40apple.com@dmarc.ietf.org>
Cc: dnssd <dnssd@ietf.org>
References: <155227670562.31093.3624881391252354593.idtracker@ietfa.amsl.com> <14d1ad00-61de-af75-8a8f-3e5bcf1fa1ef@huitema.net> <C1B9DD22-52B0-4292-AFDE-698E3CE24DAB@apple.com> <2f106571-676b-8852-5c3e-38601306f2f1@huitema.net> <D2A9DCCA-C61C-42BD-BDAD-D18EFBAE9C3C@apple.com> <179f5539-d336-6497-c027-c03686bef08c@huitema.net> <B9AE1723-9073-454F-B1B7-060AFB12287E@apple.com>
From: Christian Huitema <huitema@huitema.net>
Openpgp: preference=signencrypt
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb 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: <244e7041-4e04-f513-11ae-53ea65fafc3f@huitema.net>
Date: Mon, 11 Mar 2019 11:05:43 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3
MIME-Version: 1.0
In-Reply-To: <B9AE1723-9073-454F-B1B7-060AFB12287E@apple.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Originating-IP: 168.144.250.234
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: EX5BVjFpneJeBchSMxfU5nwyZMrF0z2P0TII8jCfDkd602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzXMPpKBnlzcICbdbWbUSKtVjyn5UrUp4n4yKOOaq9AxYo4FYp2ewVgBUerfHNSxllDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5CmLguVI7uaKQZnk5mHowEU5EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhwZ+JqwRq4dm7gx9VmMD3oQl+86MkQJ6nrl0gGH3bP6cMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjMauXIUif1JzGdiG0o4ggCmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJE2d52fY0d/1mkgffWkdO 4QEiRQv+PVjjwa+Z5RFCOMR0q/8r+vli3P7r8BoPzXffG1JhEiAOdl0Bn/vyebShl118+4clI49c e/taUHgRz0tqJvBXd7I82n0qpCzrPWiSwKPXNKNk2RVY2K5nyLgw1RWkNIWnHjoiI9QIik6sV5hq 8RGminksXtFq8ejOBuf1PiUt8a2Lj9MmCjDfgJI6+ZbV1QYTPnZGbiCKnPeJqXuDg5/bq7ChmPMN Ycw1QSmRfZlIEJPHyZ+eybTLO9HCvp2GGX0sH6lEDpvBkSUS6Qtm4zuNRcgRKiGg7nXFaZTxCXRq rnqpvNj9xYi9OgZhiukzbVwTlpzEqQskUS84syO+NTKQHNkjJg8xvPcdYB8Xlm45eDKY0zTzJ2HG 4elPGf27lItOpPwlvQ6ktwDuRituj6ZEfB9v4x8THVh0rVtlyOZYRaCjaXhrY3nerbmurCmoQsay Zkd2YakTHWoyevr4xM5tUrEfL92iWzfzWX2vc1ctxv2vDEIpeWV/lG6Wmg==
X-Report-Abuse-To: spam@quarantine9.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/ukORckVo29uIznzGUiLJlv5Szlo>
Subject: Re: [dnssd] New Version Notification for draft-huitema-dnssd-tls-privacy-00.txt
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: Mon, 11 Mar 2019 18:06:17 -0000

On 3/11/2019 8:33 AM, Bob Bradley wrote:

>
> 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.


I think the use of server keys is more natural. There are many
deployments in which the server does not identify the individual
clients. I also think that for peer-to-peer applications it does not
matter, because each peer can act as either server or client depending
on circumstances.

When I look at this thread, I think that the "excessive multicast"
issues that you mention could be solved with a server broadcast message,
"server X is now present on this network". It would be secured with the
server discovery key, so only authorized clients would understand it.
But i am concerned that this is a high cost and high risk message. High
cost, because all clients need to run the trial description against all
server keys that they know about, which has an O(N^2) feeling. Even if
we discard the cost, the high risk is the replay attack.

Suppose that an attacker has identified a server, and is capable of
recording the broadcast announces from that server. The attacker can
then replay the message, triggering paired clients to attempt
communicating with the server. The attacker does not need to break any
key, it just takes note of the addresses of the device responding to the
server. I think we need a protection against the two variants of that
attack: replay at a different time; and, replay at a different location.

Of these, protection against replay in time is the easier -- just add a
time stamp in the server's announce, an program the clients to discard
old messages. Protection against replay at a different location would
require adding a location information in the server's announce, and have
clients discard the message if the location is not what they expect.
Maybe the server could just copy their IPv6 address, and the client
would be able to verify that the prefix is local.

The same replay attack is also possible with the "client hello" proposal
discussed in the draft, but the messages are much less powerful -- they
are meant to trigger just one answer from one targeted server, not N
answers from all the clients that happen to be present.

-- Christian Huitema