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

[Douglas Otis <[e-mail]>]

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

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.  


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

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. 

Regards,
Douglas Otis