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

[Douglas Otis <[e-mail]>]

> On Mar 13, 2015, at 1:41 PM, Kerry Lynn <[e-mail]> wrote:
> 
> On Thu, Mar 12, 2015 at 2:24 PM, Douglas Otis <[e-mail]> wrote:
> 
> > On Mar 10, 2015, at 4:04 PM, Stephen Farrell <[e-mail]> wrote:
> >
> > Stephen Farrell has entered the following ballot position for
> > draft-ietf-dnssd-requirements-05: No Objection
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> > The document, along with other ballot positions, can be found here:
> > http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > - section 6 intro: I'm not sure I buy that the set of relevant
> > threats is only a union as stated. There are often new threats
> > in new environments.
> >
> <KEL> The current text reads "likely to include the union...", not "only the union..."
> 
> > - 6.6: I think one can also leak private information by
> > searching in too broad a scope, e.g. if the client can be
> > fingerprinted allowing re-identification. I think that's
> > different from the example given, and maybe worth noting too.
> 
> <KEL> The current plan is to produce a separate security threats document; see
> https://tools.ietf.org/id/draft-rafiee-dnssd-mdns-threatmodel-01.txt.  We will make
> sure to include this issue (although I'm not sure at this point if/how a DNS-SD
> query would differ significantly from a DNS query in that respect).
> 
> I feel that the current Requirements draft represents a consensus of the WG (but
> not unanimity, as can be seen below):
> 
> 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?

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. 

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.  

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

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

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

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

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

> 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