Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT)

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 17 March 2015 19:58 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7151A1B64; Tue, 17 Mar 2015 12:58:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 AyGRO77m3VyX; Tue, 17 Mar 2015 12:58:45 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B77B1A88D5; Tue, 17 Mar 2015 12:58:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C2DF5BE56; Tue, 17 Mar 2015 19:58:40 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxb1PbneSaIz; Tue, 17 Mar 2015 19:58:39 +0000 (GMT)
Received: from [10.87.48.73] (unknown [86.46.20.71]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 82CA5BE54; Tue, 17 Mar 2015 19:58:39 +0000 (GMT)
Message-ID: <5508876F.9030904@cs.tcd.ie>
Date: Tue, 17 Mar 2015 19:58:39 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Ralph Droms <rdroms.ietf@gmail.com>
References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> <2C1D6897-BE72-4902-97A6-C5C6943B1EF7@gmail.com>
In-Reply-To: <2C1D6897-BE72-4902-97A6-C5C6943B1EF7@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnssd/Cy6s4eo0A2FRXsbcoF6iLj1DzUM>
Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, The IESG <iesg@ietf.org>, Chown Tim <tjc@ecs.soton.ac.uk>
Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT)
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Tue, 17 Mar 2015 19:58:46 -0000

Hi Ralph,

Those are comments such that I'm fine if you prefer no change.

One this one...

On 17/03/15 17:51, Ralph Droms wrote:
> Kerry pointed out that the difference between the threat from
> searching for services as opposed to other forms of name resolution
> in arbitrary zones is unclear.  While it would be possible to edit
> this text to include searching as well as registration, I think the
> resulting text would be too restrictive to allow for useful
> solutions.  Would you be willing to accept the text as it exists or
> do you have some other new text to suggest?

I don't have text to suggest sorry. The concern here is that
client devices will issue searches that, as a result of dnssd,
will be broadcast further than previously and perhaps further
than the client device maker expected. That could allow for
device/user fingerprinting/re-identification in a more
widespread domain than was previously the case. For example,
a bad actor could install something on a campus network that'd
spot and record such details, perhaps in the hope of breaking
into the client device (if they can fingerprint it as one
with a specific vulnerability).

I don't think I saw that noted in the draft but in any case
what'll eventually matter is that the eventual protocol does
not make such things worse. Noting them here would probably
make it more likely we get a good result, but isn't entirely
needed.

S.