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

[Tom Pusateri <[e-mail]>]

> On Mar 17, 2015, at 3:58 PM, Stephen Farrell <[e-mail]> wrote:
> 
> 
> Hi Ralph,
> 
> Those are comments such that I'm fine if you prefer no change.
> 
> One this one...
> 
> On 17/03/15 17:51, Ralph Droms wrote:
>> Kerry pointed out that the difference between the threat from
>> searching for services as opposed to other forms of name resolution
>> in arbitrary zones is unclear.  While it would be possible to edit
>> this text to include searching as well as registration, I think the
>> resulting text would be too restrictive to allow for useful
>> solutions.  Would you be willing to accept the text as it exists or
>> do you have some other new text to suggest?
> 
> I don't have text to suggest sorry. The concern here is that
> client devices will issue searches that, as a result of dnssd,
> will be broadcast further than previously and perhaps further
> than the client device maker expected. That could allow for
> device/user fingerprinting/re-identification in a more
> widespread domain than was previously the case. For example,
> a bad actor could install something on a campus network that'd
> spot and record such details, perhaps in the hope of breaking
> into the client device (if they can fingerprint it as one
> with a specific vulnerability).
> 
> I don't think I saw that noted in the draft but in any case
> what'll eventually matter is that the eventual protocol does
> not make such things worse. Noting them here would probably
> make it more likely we get a good result, but isn't entirely
> needed.
> 
> S.

I'm not sure I understand your scenario.

Clients issue searches in the form of unicast DNS queries to DNS servers (or proxies). This is the same as with wide-area bonjour. Only now, this may cause the proxies to issue their own multicast queries on a local network in order to ensure their cache is current. The original client's searches are never broadcast further than they were before. A bad actor would have to intercept the unicast queries from the client (which may be TLS encoded). To do this, the bad actor must have compromised some network device to do this.

Tom