Subject: [dnssd] New version of Threat Model

From: Hosnieh Rafiee <[email-masked]>
Date: Wed, 9 Jul 2014 13:54:23 +0000

Folks,

Unfortunately I didn't have a chance to upload this version before deadline. This is why I share it again on the following link until the IETF servers are open again and accepts upload

<http://editor.rozanak.com/show.aspx?u=AZA480F5860A181786C3B7TAM>

There one important question that I also raised it offlist to the chairs
- Do we want to have a separate document for Threat model and solutions or you plan to merge this document to Requirement document?

I have not received any serious request for helping to improve this document. The two that asked me off-list and I gave them access did not really contribute.
 If anybody would like to be a co-author or contribute, please contact me.

I also read the requirement document and I think only we need to be careful with the edge devices and how to filter mDNS/DNS-SD messages to avoid propagating these messages over the enterprise networks and to the internet!

Thank you,
Best,
Hosnieh

---

From: Douglas Otis <[email-masked]>
Date: Wed, 9 Jul 2014 15:22:05 -0700

> I also read the requirement document and I think only we need to be careful with the edge devices and how to filter mDNS/DNS-SD messages to avoid propagating these messages over the enterprise netw…

Dear Hosnieh,

In general, you raise valid concerns.  Use of DNS-SD to merge isolated links expects layer 3 routing while permitting use of multiple prefixes.  Routable rather than link-local addresses is to be used in support of the currently defined hybrid scheme.  While I would like to collaborate, your review still misses the fundamental threats created by the hybrid scheme beyond those where internal spoofing occurs.  The basis for mDNS is to leverage the relative security of restricted access to local-link where control of hosted systems are assumed.   Some suggest a split-horizon DNS configuration can secure information contained that can otherwise permit malefactors direct access from the Internet.  By ignoring a ULA overlay, this prevents a means to algorithmically confirm source locality.  As such simply securing a printer remains impractical.  Issues you raise seems to be of a secondary concern.

Regards,
Douglas Otis

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 15 Jul 2014 09:24:42 +0300

Few points:

- Definition of ‘mdns gateway’ is missing, and it _apparently_ refers to mdns proxy (mdns-extend reference somewhere). Or not.

- mdns-extend, hybrid proxy and plain dns-sd have typically somewhat different threat models. I would rather see them separated than mixed as they are presented now. 
(I believe there’s only some hybrid threats that are valid, some marked hybrid, some not, and most of the threats apply mainly to mdns in general and mdns-extend application of it in particular). There’s also some dns-sd only ones (dns update) in a document that claims to deal with mDNS threats..

- I don’t understand what fourth attack in 3.2 is.

- I don’t believe 3.6.1/3.7.1 really belong in this document (not really usable solutions for most cases due to needing lots of provisioned configuration) but move to section 4.5+ if you think they’re really relevant?

- 3.7 - what are these ‘leave message’s anyway, ttl=0 or something? 

- 3.8 - where did the DNS update even come to this? neither mdns-extend or hybrid proxy do it, and you call document ‘mdns threat model and security consideration’. hmm.

- I would probably move number of things under 4.3 to 4.5, but that’s just my pessimism at work, perhaps..

Summary: I think this document needs bit more focus - _please_ identify which solutions have which threats that apply

Cheers,

-Markus