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

Tom Pusateri <pusateri@bangj.com> Mon, 16 March 2015 19:52 UTC

Return-Path: <pusateri@bangj.com>
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 8C0781A9057; Mon, 16 Mar 2015 12:52:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.861
X-Spam-Level:
X-Spam-Status: No, score=0.861 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 TnDBz8MTi9ch; Mon, 16 Mar 2015 12:52:21 -0700 (PDT)
Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01F791A1B78; Mon, 16 Mar 2015 12:52:21 -0700 (PDT)
Received: from [192.168.1.123] (unknown [216.16.214.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 0E22A208C; Mon, 16 Mar 2015 15:48:06 -0400 (EDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_FEADF599-6400-4DB6-AF1D-D7A20ACBC882"; protocol="application/pgp-signature"; micalg="pgp-sha1"
X-Pgp-Agent: GPGMail 2.5b5
From: Tom Pusateri <pusateri@bangj.com>
In-Reply-To: <9FC464C2-79E9-477D-9AFA-4C247F071677@gmail.com>
Date: Mon, 16 Mar 2015 15:52:09 -0400
Message-Id: <AAC2A111-A75E-48A5-8270-187DBBB109FB@bangj.com>
References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> <83452A4F-D738-43D5-85FD-316B0DC8509F@gmail.com> <CABOxzu1Fq=O_4xtWUXFB82=fudhTE2Qd0FyD1wSRntsLaEiJiQ@mail.gmail.com> <9FC464C2-79E9-477D-9AFA-4C247F071677@gmail.com>
To: Douglas Otis <doug.mtview@gmail.com>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnssd/Dfic0cptXORe-VQrc-cArKHcFuY>
Cc: Kerry Lynn <kerlyn@ieee.org>, dnssd-chairs@ietf.org, draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, Tim Chown <tjc@ecs.soton.ac.uk>, The IESG <iesg@ietf.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
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: Mon, 16 Mar 2015 19:52:23 -0000

> On Mar 13, 2015, at 10:08 PM, Douglas Otis <doug.mtview@gmail.com> wrote:
> 
> 
>> On Mar 13, 2015, at 1:41 PM, Kerry Lynn <kerlyn@ieee.org> wrote:
>> 
>> On Thu, Mar 12, 2015 at 2:24 PM, Douglas Otis <doug.mtview@gmail.com> wrote:
>> 
>> Dear Stephen,
>> 
>> I agree with your statement and, based on our tests, these concerns are very real!
>> 
>> IPv6 can not be defended in the same manner as with IPv4.  With Homenet, an
>> effort was made to ensure address selection preferences critical when
>> publishing addresses within DNS but omitted from the requirements documents.
>> 
>> <KEL> Doug, can your concern be addressed by specifically stating a requirement
>> that advertising a service in the global internet should be an opt-in decision of the
>> user, as suggested by Benoit?

I'm not sure how practical this is. In order to work with existing service advertisements, these decisions should be made in the device that translates the mDNS advertisements not the device that originates the advertisement. But there is plenty of room for policy controls in the translation device to filter and provide access control based on local criteria.

> Dear Kerry,
> 
> Thank you for you comments.  See reply below.
> 
>> The statement made in Section 6.1 is poorly considered.
>> ,--
>> Section 6.1
>> ...
>> Note that discovery of a service does not necessarily imply that the
>> service is reachable by, or can be connected to, or can be used by, a
>> given client.  Specific access control mechanisms are out of scope of
>> this document.
>> '---
>> 
>> <KEL> Let's take these "poorly considered" assertions one-by-one:
>>  - reachable (a route may not exist to the advertised address)
>>  - connected to (the device may be offline)
>>  - used by (the user of the service may lack authorization)
>>  - access control is out of scope (not in our charter)
>> Which of these do you specifically have an issue with?
> 
> Controlling access becomes unmanageable with automatic expansion of --
> 
> a) discovery of all network details reported by mDNS beyond local networks
> 
> b) routing beyond local networks using all mDNS details conveyed to DNS
> 
> For example, an older Mac Book excluded from receiving security updates
> fixing an NTP DDOS vulnerability, a concern that applies equally to any
> consumer device placed at risk by unwarrantedly increased discovery.
> Examples might include printers or a baby monitors heavily depending
> on access limited to local networks which conflicts with a goal of
> reduced dependence on multi-cast discovery.
> 

I don't agree. Controlling access is perfectly manageable and done by a variety of institutions across a broad array of services. Do not  incorrectly equate discovery with access.

> A typical IPv6 router is unable to differentiate hosts given a routable
> address published in DNS by an mDNS proxy.  To safely bridge this gap,
> address preferences MUST USE the smallest practical scope available.  The
> ability to do so MUST BE a requirement.  As such, direct Internet
> access would require other methods be used.  This means there MUST BE a
> requirement to understand address scope differentiation. A requirement
> related to mDNS --> DNS publication that is missing.

While a device translating multicast DNS services to a unicast DNS infrastructure MAY choose to limit the scope of the addresses it advertises, this is not a MUST and the smallest scope MAY NOT be the correct scope. This decision is best left to the administrator of the translating device and we should not limit the applicability of the protocol meeting these requirements.

> 
> Once a malefactor discovers addresses having global scope not uniquely
> identifiable at a firewall, an entire class of devices immediately become
> vulnerable.

These devices are vulnerable regardless and to pretend otherwise is just an attempt to derail this effort. There are many ways to discover internal devices without DNS-SD service advertisements.

> 
> As with Homenet, mDNS to DNS proxy should prefer the most conservative scope
> that meets the desired goals.

This is a good recommendation but it SHOULD be up to the administrator of the translating device.

> 
> When done correctly, this should not require an Internet Opt-in mechanism
> that is impractical for hosts assigned global IPv6 addresses.

Agreed. Opt-in or Opt-out mechanisms are not practical when considering existing services.

> 
>> Or the false statement:
>> ,--
>> 6.5.  Access Control
>> ...
>> While controlling access to an advertised service is outside the
>> scope of DNS-SD, we note that access control today often is provided
>> by existing site infrastructure (e.g., router access control lists,
>> firewalls) and/or by service-specific mechanisms (e.g., user
>> authentication to the service).  For example, networked printers can
>> control access via a user-id and password.  Apple's software supports
>> such access control for USB printers shared via Mac OS X Printer
>> Sharing, as do many networked printers themselves.  So the reliance
>> on existing service-specific security mechanisms (i.e. outside the
>> scope of DNS-SD) does not create new security considerations.
>> '---
>> 
>> Most printers DO NOT offer user-id/password access mechanisms and often
>> IPv6 support removes access control lists.  Homenet and Apples BTMM
>> make use of an important overlay approach being ignored both here and with
>> the the insecure UPnP. For this protocol to safely interoperate, an
>> overlay approach must be supported.  This approach might use ULAs, for
>> example. For this to work properly, locally defined addresses must be
>> preferred when publishing in DNS.
>> 
>> As previously presented, it is minor fix to correct this oversight.
>> 
>> <KEL> Doug, you have had ample opportunity to argue your position before
>> the WG and again during WGLC.  Your concern has been duly noted, but it
>> is not the consensus of the WG to mandate a particular solution in an
>> *informative* requirements draft.
> 
> The suggestion was to consider Homenet and to leverage their consensus.
> 
> There was very little discussion within this WG, other than to deny concerns at
> the beginning and final hours.  A point in time which excluded my participation due
> to momentary health issues.

There was ample discussion of this topic in the working group including your participation. This text accurately represents the consensus of the working group. Stuart described how these services could be secured with user authentication today and products that are vulnerable are vulnerable with or without service discovery advertisements.

> 
>> To your point about specific devices lacking access control mechanisms, my
>> personal response would be to a) mitigate that problem with an appliance (such
>> as described in http://spectrum.ieee.org/telecom/security/how-to-build-a-safer-internet-of-things),
>> b) put it behind a device that implements access control (e.g. a Mac- or PC-to-
>> USB print server), c) get a printer that supports access control (yes, they do exist),
>> or d) don't advertise the service beyond the local link.
> 
> Firewall policies white-listing specific IPv6 addresses is not practical.  This is why
> such a feature is often excluded in IPv6 supported devices, yet present with IPv4.

Same as above. DNS-SD can't be responsible for broken products that are vulnerable with or without service discovery advertisements. Policy at the translating device is no different for IPv6 as it is for IPv4. NAT is not a security solution.

> 
>> Note that in the topologies we're specifically targeting (enterprise, higher ed)
>> implementing an overlay is no guarantee that an adversary with access to the
>> network won't be able to use your consumables (ink & paper).
> 
> Doing this for higher education is great.  However, there is no reason this can't be
> done in a safer manner by requiring a few basic functional requirements still missing.
> 
> See:
> RFC7368 Section 3.6.6.  ULAs as a Hint of Connection Origin
> RFC7084 Section 4.1  General Requirements
> RFC7068 Section 4.3.  LAN-Side Configuration
> RFC4864 Section 3.2.  Unique Local Addresses
> 
> Omitting proper address selection rules will not ensure basic deployments offer desired security.  This consideration was omitted in both the Hybrid Proxy and the requirements documents. Threat related documents should also include header compliance requirements as specified by RA Guard RFC7113 also omitted by this draft to better ensure administrative control of host naming conventions in lieu of IDNA naming restrictions.
> 
> Again, the issue is to get ahead of security threats.  We have the opportunity to do this correctly - and at virtually no cost.  If we wait, it will be deployed, and exploited at great cost.
> 
> Regards,
> Douglas Otis

These are good recommendations for an administrator but again I don't see the need to force it as a requirement. That will restrict the use cases. The use case you are thinking of MAY benefit from this approach and you may even want to make defaults that guide the administrator in this way but by no means will it apply to every use case.

I don't see anything new here.

Tom