Re: [dnssd] WGLC on draft-ietf-dnssd-privacy-01

Christian Huitema <huitema@huitema.net> Mon, 26 June 2017 14:18 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 088FE12EA55 for <dnssd@ietfa.amsl.com>; Mon, 26 Jun 2017 07:18:29 -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 O3vB_zW0xe0x for <dnssd@ietfa.amsl.com>; Mon, 26 Jun 2017 07:18:27 -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 DF6F0129B91 for <dnssd@ietf.org>; Mon, 26 Jun 2017 07:18:26 -0700 (PDT)
Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from <huitema@huitema.net>) id 1dPUqO-0006Zv-49 for dnssd@ietf.org; Mon, 26 Jun 2017 16:18:25 +0200
Received: from [10.5.2.15] (helo=xmail05.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 1dPUqI-0000at-Tp for dnssd@ietf.org; Mon, 26 Jun 2017 10:18:22 -0400
Received: (qmail 16461 invoked from network); 26 Jun 2017 14:18:16 -0000
Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.56.42.244]) (envelope-sender <huitema@huitema.net>) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for <dnssd@ietf.org>; 26 Jun 2017 14:18:16 -0000
To: dnssd@ietf.org
References: <CF1BAEAE-41C7-4E69-AD6F-9F31E7C7B2A3@jisc.ac.uk> <20170625210709.GA829@sources.org>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <28c0ad99-2905-64b6-52c2-a357e7fa6d12@huitema.net>
Date: Mon, 26 Jun 2017 07:18:19 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <20170625210709.GA829@sources.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: 168.144.250.190
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.33)
X-Recommended-Action: accept
X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJYoNzrMVvavOgy+9M5kGys4ND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23m1GrkYo/0Y92Y6E22NNnpuoI9GlgXFbGvhvB 71hlmrqRz3KkGpwt7JVVRkGXTRxiYOEkjsX7F8KmpUaZQHV+ScWIfGf9Fu8q9UhMPe0GR5O2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpKs+iZ7+uSas6Kaz0EAgJQD6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGyZtV8+oD7aoVwvnjslfJzo/eNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj234Kahp30YSTh5OL3yMqjF0jNdSMuNhZC3X/nGdDKYyg+1Fotn1TGspRGWfHjmaruO0b XpkevaElTi+sCWwmqxHi+BUHXGjp0J8FpT+J6AFTxiSsoNTiR/GmpPv4QzJ0uLs078I0y+3uS4dN KiUgYTBUyJWZ26+gPs1bzv8LK3hJrYAbiteDwjw8P7mx/NBHSRWxZaHLvUGmD7PXY2RS8idsz7fr MHsNPRylYAkPvY1HttQOF909qtkcRbvucYBIc/SWdEVhFWVNeXUVBER+dDF8MLn6MURQGfriekzS 9Ga3AA==
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/8OlpvoehrRWZFOvZOV3Ky4R44sM>
Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-privacy-01
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.22
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, 26 Jun 2017 14:18:29 -0000


On 6/25/2017 2:07 PM, Stephane Bortzmeyer wrote:
> On Mon, Jun 19, 2017 at 02:24:36PM +0000,
>  Tim Chown <Tim.Chown@jisc.ac.uk> wrote 
>  a message of 38 lines which said:
>
>> We are initiating a WG Last Call today on
>> draft-ietf-dnssd-privacy-01, as can be found at
>> https://tools.ietf.org/html/draft-ietf-dnssd-privacy-01
> Read it and it seems OK to me. But I see one technical weakness, and
> two things that I find puzzling.
Thanks for the review.

> In section 3.2.2, if I understand correctly the proposal for a
> predictable nonce, it seems to me it has a weakness: end-users
> machines do not always have proper clock synchronisation (see also 5.5
> which mentions it, for an unrelated issue). True, taking only the
> first 24 bits of the time will help (some machines with different
> clocks will nevertheless end in the same time interval), but it is not
> sufficient if bad luck makes two machines fall in different intervals.
True. The solution requires that the participating devices have "good
enough" clocks -- to the minute, in practice. It is clearly a trade off
between usability and performance, and also resistance to DOS. The
initial design had unconstrained nonce instead. The problem with
unconstrained nonce is that they cannot be pre-computed by the peer,
which open the possibility of a DOS attack: creates many nonces, and
force the peer to compute as many hashes. Besides, nonces have a
weakness too -- end-user machines do not always have proper sources of
randomness.

So in practice we require end users machines to have some sense of time.
Maybe we should be more upfront about that.

> In section 2.4 "There is however an argument that devices providing
> services can be discovered by observing the local traffic" Another
> weakness of this argument is not mentioned: mDNS is multicasted so
> anyone can listen, eve on a switched network. Local traffic isn't.
Good point. Will fix that text.
> In section 3.4, "Host names are typically not visible by the users,
> and randomizing host names will probably not cause much usability
> issues." Is it always true? It seems to me several discovery protocols
> (over Bluetooth for instance) display the host name to the end user.
In DNS-SD, host names are not meant to be visible. The UI examples all
use the instance name.

We did consider something like an aliasing system for host names. Once
devices have recognized each other, they could "decrypt" the host name,
so applications could use it directly.

Any suggestion?

-- Christian Huitema