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

[Tom Pusateri <[e-mail]>]

> On Mar 10, 2015, at 7: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.
> 

Maybe this text would be more clear for the introduction:

Insofar as SSD may automatically gather DNS-SD resource records and
publish them over a wide area, the security issues that could
be discussed here include the security issues already discussed
in the Multicast DNS and DNS-Based Service Discovery specifications.
We will not re-discuss those issues here. Please see those
specifications for a detailed discussion of those common issues.
In this section we will discuss new potential threats that are
posed by deploying DNS-SD over multiple links or by automating
DNS-SD administration.


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


The scope of the search is based on the domain name in the request and is perfectly controllable by the client. Unicast queries for PTR service records in no way leaks any more private information about the client than unicast queries for A records.

Thanks,
Tom