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

Stephane Bortzmeyer <> Sun, 25 June 2017 21:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 30ABC1243FE for <>; Sun, 25 Jun 2017 14:08:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bMVxsV9cJWJv for <>; Sun, 25 Jun 2017 14:08:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 418E01200CF for <>; Sun, 25 Jun 2017 14:08:12 -0700 (PDT)
Received: by (Postfix, from userid 10) id E611E31D29; Sun, 25 Jun 2017 23:08:06 +0200 (CEST)
Received: by (Postfix, from userid 1000) id 14169190C3E; Sun, 25 Jun 2017 23:07:10 +0200 (CEST)
Date: Sun, 25 Jun 2017 23:07:10 +0200
From: Stephane Bortzmeyer <>
To: Tim Chown <>
Cc: "" <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
X-Transport: UUCP rules
X-Operating-System: Debian GNU/Linux 8.8
X-Charlie: Je suis Charlie
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-privacy-01
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 25 Jun 2017 21:08:15 -0000

On Mon, Jun 19, 2017 at 02:24:36PM +0000,
 Tim Chown <> 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

Read it and it seems OK to me. But I see one technical weakness, and
two things that I find puzzling.

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.

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.

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.