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

[Douglas Otis <[e-mail]>]

Dear Ralph,

> On Mar 17, 2015, at 10:58 AM, Ralph Droms <[e-mail]> wrote:
> 
> Doug - Here is my summary of what I understand to be your concerns with
> draft-ietf-dnssd-requirements-05:
> 
> 1) A change from link-scope mDNS SD to a larger scope may result in the
> existence and address of a device being made more widely available than
> currently expected.

Of course.

> 2) Some devices and networks are incapable of defending themselves
> against unwanted access or other attacks once the address of the device
> to be attacked is known.

When the _wrong_ address is published within DNS that then permits direct
Internet access, this may evade desired protections. Although many mDNS
devices report all such options, such reporting is only seen on the local 
network.    

> 3) Use of RFC 4193 is a way to protect against attacks enabled by the
> increased scope of discovery envisioned by extended DNS-SD.

Use of RFC4193 is used to protect Homenet as well as various enterprise
environments.  It is also used by Apple in their Back-To-My-Mac scheme.

> You expressed these concerns during WG development and review of
> draft-ietf-dnssd-requirements.  Tim and I judged the consensus of the
> WG to be in support of advancing the document to the IESG, based in part
> on the following analysis:
> 
> Points 1 and 2 are answered by the third paragraph of section 6.1.  For
> completeness, the last sentence of that paragraph might be extended to
> include "and protection against other forms of attack".

Address selection preferences represent critical security aspects that 
MUST BE supported by the protocol.  If RFC1918 or RFC4193 addresses are 
reported via mDNS to the  DNS-SD proxy, there MUST be a requirement for 
these addresses to be used over any Internet routable address.  It is 
important these requirements make it clear mDNS is not suitable for 
publishing hosts on the Internet.  Where safer alternatives exist, such 
publication MUST REQUIRE administrative intervention.  Otherwise 
organizations making use of such schemes will be placed at great risk. 

> 
> Point 3 tries to mandate a solution through a specific deployment
> mechanism and is, therefore, out of scope for a requirements document.
> It may also be more broadly out of scope of the dnssd charter, which
> addresses just DNS-based service discovery and does not include mandating
> network deployment requirements as part of a solution.

This point offers an example strategy (address preferences) that MUST be 
supported.  Ensuring support is not the same as making this a mandate!  
It seems clear this group failed to develop schemes to protect devices 
that normally limit access to that of the local network, as provided by 
constraints imposed by mDNS.  As such, there should have been greater 
review of those offered by Homenet or even Back-To-My-Mac.

> If you do not agree that your concerns have been answered by this
> analysis, please state the basis for your continued concern, so that we
> can judge rough consensus on support for publication of the document.

The requirements document remains critically flawed without justification. 
Ensuring an ability to offer safe deployment unfortunately does not prevent 
less safe schemes. Nevertheless, supporting a safe scheme should be a basic 
requirement. 

Regards,
Douglas Otis