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

[Kerry Lynn <[e-mail]>]

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?

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

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.

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.

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

Regards, Kerry Lynn

Regards,
> Douglas Otis
> _______________________________________________
> dnssd mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnssd
>