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

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 10 Mar 2015 16:04:33 -0700

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.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 12 Mar 2015 11:24:53 -0700

> On Mar 10, 2015, at 4:04 PM, Stephen Farrell <[email-masked]> wrote:
> 

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

---

From: Douglas Otis <[email-masked]>
Date: Thu, 12 Mar 2015 11:24:53 -0700

Dear Stephen,

Or the false statement:
,--
6.5.  Access Control
 ...

Regards,
Douglas Otis

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 13 Mar 2015 16:41:16 -0400

> > http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/
<KEL> The current text reads "likely to include the union...", not "only
the union..."

> <KEL> The current plan is to produce a separate security threats document;
see
https://tools.ietf.org/id/draft-rafiee-dnssd-mdns-threatmodel-01.txt.  We
will make
sure to include this issue (although I'm not sure at this point if/how a
DNS-SD
query would differ significantly from a DNS query in that respect).

I feel that the current Requirements draft represents a consensus of the WG
(but
not unanimity, as can be seen below):

 Dear Stephen,
> <KEL> Doug, can your concern be addressed by specifically stating a
requirement
that advertising a service in the global internet should be an opt-in
decision of the
user, as suggested by Benoit?

> <KEL> Let's take these "poorly considered" assertions one-by-one:
  - reachable (a route may not exist to the advertised address)
  - connected to (the device may be offline)
  - used by (the user of the service may lack authorization)
  - access control is out of scope (not in our charter)
Which of these do you specifically have an issue with?

Or the false statement:
> <KEL> Doug, you have had ample opportunity to argue your position before
the WG and again during WGLC.  Your concern has been duly noted, but it
is not the consensus of the WG to mandate a particular solution in an
*informative* requirements draft.

To your point about specific devices lacking access control mechanisms, my
personal response would be to a) mitigate that problem with an appliance
(such
as described in
http://spectrum.ieee.org/telecom/security/how-to-build-a-safer-internet-of-things
),
b) put it behind a device that implements access control (e.g. a Mac- or
PC-to-
USB print server), c) get a printer that supports access control (yes, they
do exist),
or d) don't advertise the service beyond the local link.

Note that in the topologies we're specifically targeting (enterprise,
higher ed)
implementing an overlay is no guarantee that an adversary with access to the
network won't be able to use your consumables (ink & paper).

Regards, Kerry Lynn

Regards,
> Douglas Otis
> _______________________________________________
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd
>

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 13 Mar 2015 16:41:16 -0400

see

 Dear Stephen,
requirement

Regards, Kerry Lynn

Regards,

---

From: Douglas Otis <[email-masked]>
Date: Fri, 13 Mar 2015 19:08:49 -0700

> On Mar 13, 2015, at 1:41 PM, Kerry Lynn <[email-masked]> wrote:
> 
> <KEL> The current text reads "likely to include the union...", not "only the union..."
> 
> <KEL> The current plan is to produce a separate security threats document; see
> https://tools.ietf.org/id/draft-rafiee-dnssd-mdns-threatmodel-01.txt.  We will make
> sure to include this issue (although I'm not sure at this point if/how a DNS-SD
> I feel that the current Requirements draft represents a consensus of the WG (but
> <KEL> Doug, can your concern be addressed by specifically stating a requirement
> that advertising a service in the global internet should be an opt-in decision of the

Dear Kerry, 

Thank you for you comments.  See reply below. 

> Which of these do you specifically have an issue with?

Controlling access becomes unmanageable with automatic expansion of --

a) discovery of all network details reported by mDNS beyond local networks

b) routing beyond local networks using all mDNS details conveyed to DNS

For example, an older Mac Book excluded from receiving security updates 
fixing an NTP DDOS vulnerability, a concern that applies equally to any
consumer device placed at risk by unwarrantedly increased discovery.
Examples might include printers or a baby monitors heavily depending
on access limited to local networks which conflicts with a goal of
reduced dependence on multi-cast discovery. 

A typical IPv6 router is unable to differentiate hosts given a routable
address published in DNS by an mDNS proxy.  To safely bridge this gap,
address preferences MUST USE the smallest practical scope available.  The 
ability to do so MUST BE a requirement.  As such, direct Internet
access would require other methods be used.  This means there MUST BE a
requirement to understand address scope differentiation. A requirement
related to mDNS --> DNS publication that is missing.  

Once a malefactor discovers addresses having global scope not uniquely
identifiable at a firewall, an entire class of devices immediately become
vulnerable. 

As with Homenet, mDNS to DNS proxy should prefer the most conservative scope
that meets the desired goals.

When done correctly, this should not require an Internet Opt-in mechanism 
that is impractical for hosts assigned global IPv6 addresses.

> *informative* requirements draft.

The suggestion was to consider Homenet and to leverage their consensus.

There was very little discussion within this WG, other than to deny concerns at
the beginning and final hours.  A point in time which excluded my participation due
to momentary health issues.

> personal response would be to a) mitigate that problem with an appliance (such
> as described in http://spectrum.ieee.org/telecom/security/how-to-build-a-safer-internet-of-things),
> b) put it behind a device that implements access control (e.g. a Mac- or PC-to-
> USB print server), c) get a printer that supports access control (yes, they do exist),

Firewall policies white-listing specific IPv6 addresses is not practical.  This is why 
such a feature is often excluded in IPv6 supported devices, yet present with IPv4.

> Note that in the topologies we're specifically targeting (enterprise, higher ed)

Doing this for higher education is great.  However, there is no reason this can't be
done in a safer manner by requiring a few basic functional requirements still missing.

See:
RFC7368 Section 3.6.6.  ULAs as a Hint of Connection Origin
RFC7084 Section 4.1  General Requirements
RFC7068 Section 4.3.  LAN-Side Configuration
RFC4864 Section 3.2.  Unique Local Addresses

Omitting proper address selection rules will not ensure basic deployments offer desired security.  This consideration was omitted in both the Hybrid Proxy and the requirements documents. Threat related documents should also include header compliance requirements as specified by RA Guard RFC7113 also omitted by this draft to better ensure administrative control of host naming conventions in lieu of IDNA naming restrictions.

Again, the issue is to get ahead of security threats.  We have the opportunity to do this correctly - and at virtually no cost.  If we wait, it will be deployed, and exploited at great cost.

Regards,
Douglas Otis

---

From: Douglas Otis <[email-masked]>
Date: Fri, 13 Mar 2015 19:08:49 -0700

Dear Kerry, 

See:

Regards,
Douglas Otis

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 16 Mar 2015 14:10:24 -0400

> On Mar 10, 2015, at 7:04 PM, Stephen Farrell <[email-masked]> wrote:
> 

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.

> 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

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 16 Mar 2015 14:10:24 -0400

Thanks,
Tom

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 16 Mar 2015 15:52:09 -0400

> On Mar 13, 2015, at 10:08 PM, Douglas Otis <[email-masked]> wrote:
> 
> 

I'm not sure how practical this is. In order to work with existing service advertisements, these decisions should be made in the device that translates the mDNS advertisements not the device that originates the advertisement. But there is plenty of room for policy controls in the translation device to filter and provide access control based on local criteria.

> reduced dependence on multi-cast discovery.

I don't agree. Controlling access is perfectly manageable and done by a variety of institutions across a broad array of services. Do not  incorrectly equate discovery with access.

> related to mDNS --> DNS publication that is missing.

While a device translating multicast DNS services to a unicast DNS infrastructure MAY choose to limit the scope of the addresses it advertises, this is not a MUST and the smallest scope MAY NOT be the correct scope. This decision is best left to the administrator of the translating device and we should not limit the applicability of the protocol meeting these requirements.

> identifiable at a firewall, an entire class of devices immediately become

These devices are vulnerable regardless and to pretend otherwise is just an attempt to derail this effort. There are many ways to discover internal devices without DNS-SD service advertisements.

> that meets the desired goals.

This is a good recommendation but it SHOULD be up to the administrator of the translating device.

> that is impractical for hosts assigned global IPv6 addresses.

Agreed. Opt-in or Opt-out mechanisms are not practical when considering existing services.

> to momentary health issues.

There was ample discussion of this topic in the working group including your participation. This text accurately represents the consensus of the working group. Stuart described how these services could be secured with user authentication today and products that are vulnerable are vulnerable with or without service discovery advertisements.

> such a feature is often excluded in IPv6 supported devices, yet present with IPv4.

Same as above. DNS-SD can't be responsible for broken products that are vulnerable with or without service discovery advertisements. Policy at the translating device is no different for IPv6 as it is for IPv4. NAT is not a security solution.

> Again, the issue is to get ahead of security threats.  We have the opportunity to do this correctly - and at virtually no cost.  If we wait, it will be deployed, and exploited at great cost.

These are good recommendations for an administrator but again I don't see the need to force it as a requirement. That will restrict the use cases. The use case you are thinking of MAY benefit from this approach and you may even want to make defaults that guide the administrator in this way but by no means will it apply to every use case.

I don't see anything new here.

Tom

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 16 Mar 2015 15:52:09 -0400

Tom

---

From: Douglas Otis <[email-masked]>
Date: Mon, 16 Mar 2015 18:07:33 -0700

> On Mar 16, 2015, at 12:52 PM, Tom Pusateri <[email-masked]> wrote:
> 
> I'm not sure how practical this is. In order to work with
> existing service advertisements, these decisions should be
> made in the device that translates the mDNS advertisements
> not the device that originates the advertisement. But there
> is plenty of room for policy controls in the translation device
> to filter and provide access control based on local criteria.

Dear Tom,

Automatic publishing of mDNS as DNS-SD introduces concerns NOT 
adequately covered by either mDNS or DNS-SD respective security
sections.  When either RFC1918 or RFC4193 host addresses are 
present, there is no need to expose other address categories.  After
all, mDNS is bound to local networks by limitation of multicast.  
RFC4193 offers local network containment strategies not dependent on
multicast.

Offering routable IP addresses introduces unwarranted and unnecessary
exposure when enabled beyond the local network, and it is clear such
limitations are not imposed by hosts supporting mDNS since such
exposure is expected limited by multicast constraints.  However, the
effort to automatically publish mDNS in DNS-SD form removes these
constraints and creates new risk not yet properly addressed.
    
> I don't agree. Controlling access is perfectly manageable and done
> by a variety of institutions across a broad array of services. Do not
> incorrectly equate discovery with access.

Since IPv6 permits dynamic network prefixes, this makes it relatively
impractical to exclude traffic from the Internet while allowing traffic
from isolated bridges without reliance on conventions established by
RFC4193 as used by Homenet and various enterprise deployments.

> While a device translating multicast DNS services to a unicast DNS
> infrastructure MAY choose to limit the scope of the addresses it
> advertises, this is not a MUST and the smallest scope MAY NOT be
> the correct scope. This decision is best left to the administrator
> of the translating device and we should not limit the applicability
> of the protocol meeting these requirements.

RFC4193 avoids network translations by use of a network overlay.  A
technique that leverages IPv6's ability to support multiple IP addresses
per network adapter.  Many different network boundaries can be safely
established through an address category selection made in a publication
process.  The ability to establish publication preferences MUST BE a
requirement for any proposed publications of mDNS into DNS.  Publishing
a host on the Internet SHOULD NEVER be automatic, nor depend on
administrative intervention.  The selection process using _stable_
prefixes is thereby better able to select the smallest _practical_ realm
based on administrative policy.

> These devices are vulnerable regardless and to pretend otherwise is
> just an attempt to derail this effort. There are many ways to discover
> internal devices without DNS-SD service advertisements.

An RFC4193 address better isolates sensitive devices having limited resources
from direct Internet access, while still enabling various authenticated
tunneling methods.  It is also wrong to suggest such devices are not far 
better protected by such schemes.

> This is a good recommendation but it SHOULD be up to the administrator of the

Before an administrator is able to isolate a network realm, basic support methods
must be made available as a protocol requirement.  A requirement that remains
missing in the form of address publication selection.

> There was ample discussion of this topic in the working group including
> your participation. This text accurately represents the consensus of the
> working group. Stuart described how these services could be secured with
> user authentication today and products that are vulnerable are vulnerable
> with or without service discovery advertisements.

Nevertheless, a few key statements were factually in error and challenged,
but never adequately discussed on a rather quiet WG.

> Same as above. DNS-SD can't be responsible for broken products that are
> vulnerable with or without service discovery advertisements. Policy at the
> translating device is no different for IPv6 as it is for IPv4. NAT is not a
> security solution.

This is not about use of a NAT.  With IPv6, it is about use of overlays.
These might be in the form of VLANs or VPNs for example.  Methods that are 
able to offer very strong security. 

>> Doing this for higher education is great.  However, there is
>> no reason this can't be done in a safer manner by requiring a
>> few basic functional requirements still missing.
>> 
>> See:
>> Omitting proper address selection rules will not ensure basic
>> deployments offer desired security.  This consideration was
>> omitted in both the Hybrid Proxy and the requirements documents.
>> Threat related documents should also include header compliance
>> requirements as specified by RA Guard RFC7113 also omitted by
>> this draft to better ensure administrative control of host naming
>> conventions in lieu of IDNA naming restrictions.
>> 
>> Again, the issue is to get ahead of security threats.  We have
>> the opportunity to do this correctly - and at virtually no cost.
>> If we wait, it will be deployed, and exploited at great cost.
> 
> These are good recommendations for an administrator but again I don't see
> the need to force it as a requirement.  That will restrict the use cases.

Not imposing a MUST requirement on an address selection ability prevents
safer deployment possibilities.  Security will be significantly weakened
by this address selection requirement oversight!  This scheme should also
ensure of the integrity of basic configurations being published, since
IDNA is also being ignored.

> The use case you are thinking of MAY benefit from this approach and you
> may even want to make defaults that guide the administrator in this way
> but by no means will it apply to every use case.

The current attitude is all devices inadvertently exposed by mDNS -> 
DNS-SD automatic publishing schemes will be able to cope with direct
Internet access or will be administratively excluded.  Similar attitudes
have been expressed in the past, many of which later proved recklessly
optimistic.  A few simple changes can and will significantly enhance
the ease and stability of the desired security. 

Regards,
Douglas Otis

---

From: Douglas Otis <[email-masked]>
Date: Mon, 16 Mar 2015 18:07:33 -0700

Dear Tom,

    

Regards,
Douglas Otis

---

From: Ralph Droms <[email-masked]>
Date: Tue, 17 Mar 2015 13:51:25 -0400

Stephen - let me summarize the responses to your comments; please let us know if these responses will be sufficient to address your comments...

As Kerry wrote, the text is "the security issues are likely to include the union of those discussed in the Multicast DNS [mDNS] and DNS-Based Service Discovery [DNS-SD] specifications."  Given that this text allows for other issues, and the rest of section 6 raises other issues, are you OK with the text as it exists in draft-ietf-dnssd-requirements-05?

> different from the example given, and maybe worth noting too.

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?

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Tue, 17 Mar 2015 13:51:25 -0400

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Tue, 17 Mar 2015 13:58:11 -0400

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.

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.

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

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

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.

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.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Tue, 17 Mar 2015 13:58:11 -0400

- Ralph

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 17 Mar 2015 14:22:05 -0400

> On Mar 17, 2015, at 1:51 PM, Ralph Droms <[email-masked]> wrote:
> 

I tried to make it clear in my response yesterday that this was a non-issue but maybe I wasn't as direct as I should have been.

There is no leak of private information by the client. The client is in total control of the scope and the recipient of it's query.

Tom

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 17 Mar 2015 14:22:05 -0400

Tom

---

From: Douglas Otis <[email-masked]>
Date: Tue, 17 Mar 2015 12:32:17 -0700

Dear Ralph,

> On Mar 17, 2015, at 10:58 AM, Ralph Droms <[email-masked]> wrote:
> 
> 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

---

From: Douglas Otis <[email-masked]>
Date: Tue, 17 Mar 2015 12:32:17 -0700

Dear Ralph,

Of course.

Regards,
Douglas Otis

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Mar 2015 19:58:39 +0000

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.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Mar 2015 19:58:39 +0000

Hi Ralph,

One this one...

S.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 17 Mar 2015 16:11:26 -0400

> On Mar 17, 2015, at 3:32 PM 3/17/15, Douglas Otis <[email-masked]> wrote:
> 
> Dear Ralph,
> 

I need to parse your response carefully so that we can understand each other.  In what sense is an address that permits direct address a "_wrong_" address?  Is this sentence equivalent: "When an address (such as a globally routable address) is published within DNS that then permits direct Internet access, [...]"

To make sure I understand the second sentence, is this sentence equivalent: "Although many mDNS implementations advertise all of the addresses available for a device, those advertisements are restricted to the local link and, therefore, don't advertise globally routable addresses to the Internet."

> environments.  It is also used by Apple in their Back-To-My-Mac scheme.

To be clear, you agree with my point 3 and you cite two examples of the use of RFC 4193.  My understanding is that Homenet does not mandate the use of RFC 4193, perhaps because of the difficulties in mandating such usage; from section 2.4 of RFC 7368: "Devices in a homenet may be given only a ULA as a means to restrict reachability from outside the homenet."  My understanding is that RFC 4913 addresses are used in Back-To-My-Mac as an identifier if no other IPv6 address is available, rather than to restrict reachability.  Back-To-My-Mac uses an array of other security mechanisms to protect devices using the technology.
 
> MUST BE supported by the protocol.

Do you mean selection of which among several available addresses are advertised through DNS-SD?

> If RFC1918 or RFC4193 addresses are 
> these addresses to be used over any Internet routable address.

Used where or by what devices?  Where are these restrictions enforced?

>  It is 

In my opinion, there is not consensus in the WG to support your concern.  The current text in the document represents WG consensus for the description of the potential problem.

> review of those offered by Homenet or even Back-To-My-Mac.

"example strategy [...] that MUST be supported" sounds like a mandate to me.  This is a requirements document, not a final design, and therefore this document does not need to develop a solution to the problem you are concerned with.

> less safe schemes. Nevertheless, supporting a safe scheme should be a basic 

Can you give a specific requirement or requirements that could be added to the document to satisfy your concerns?

---

From: Ralph Droms <[email-masked]>
Date: Tue, 17 Mar 2015 16:11:26 -0400

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 17 Mar 2015 16:25:11 -0400

> On Mar 17, 2015, at 3:58 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hi Ralph,
> 

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

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 17 Mar 2015 16:25:11 -0400

Tom

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Mar 2015 20:28:30 +0000

Hiya,

On 17/03/15 20:25, Tom Pusateri wrote:
> 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.

So I don't think the above is clear from the requirements draft,
which is all I've so far read. It may be clear later that there's
no significant new threat in this respect due to a specific design
having been adopted, and if so that's good.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Mar 2015 20:28:30 +0000

Hiya,

S.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 17 Mar 2015 16:03:52 -0700

Dear Ralph,

> On Mar 17, 2015, at 1:11 PM, Ralph Droms <[email-masked]> wrote:
> 
> I need to parse your response carefully so that we can understand each other.
> In what sense is an address that permits direct address a "_wrong_" address?
> Is this sentence equivalent: "When an address (such as a globally routable
> address) is published within DNS that then permits direct Internet access,
> [...]"

Many SOHO routers are unable to selectively block IPv6 session initiation from 
the Internet causing an all-or-none situation.  Necessary exceptions become 
practical when RFC1918 or RFC4193 addressing conventions are used in conjunction 
with various protocols or when they are exceptionally permitted between routers.

For example, a user with an Apple Airport Extreme router has the choice of 
allowing ALL inbound IPv6 connections, or allowing NO inbound IPv6 connections.  
There are no other options.  Similar conventions are present on virtually all 
low end routers - they simply don’t have the memory, CPU, or configuration 
capacity to allow for IPv6 access lists.  Further, with the ability for 
devices to change IPv6 addresses using the privacy extensions RFC4941, 
filtering at the router becomes impractical.  Publishing the IPv6 globally 
reachable address in DNS invites trouble, particularly for devices unsuitable
for direct internet connection (such as printers, cameras, scanners, and other
gear).

> To make sure I understand the second sentence, is this sentence equivalent:
> "Although many mDNS implementations advertise all of the addresses available
> for a device, those advertisements are restricted to the local link and,
> therefore, don't advertise globally routable addresses to the Internet."

mDNS traffic is not visible beyond the local network.  However, when globally 
routed addresses are published in DNS, exposure of this addressing might permit
malefactors access due to practical firewall limitations.  Exploits for doing 
so are many.

> To be clear, you agree with my point 3 and you cite two examples of the
> use of RFC 4193.  My understanding is that Homenet does not mandate the
> use of RFC 4193, perhaps because of the difficulties in mandating such
> usage; from section 2.4 of RFC 7368: "Devices in a homenet may be given
> only a ULA as a means to restrict reachability from outside the homenet."  
> My understanding is that RFC 4913 addresses are used in Back-To-My-Mac
> as an identifier if no other IPv6 address is available, rather than to
> restrict reachability.  Back-To-My-Mac uses an array of other security
> mechanisms to protect devices using the technology.

This overview is not correct.  ULA is NOT optional with this scheme. See:
https://tools.ietf.org/html/rfc6281

This scheme generates an IPv6 ULA for each host as its identifier.  This allows 
reuse of existing IPv6 support where end-to-end data security then depends
on IPsec to protect communications and Kerberos for end-to-end authentication.
Similar secure schemes, such as VLANs or VPNs, could also make use of these 
conventions.

> advertised through DNS-SD?

Yes, when deciding which addresses are published.

> Used where or by what devices?  Where are these restrictions enforced?

This REQUIRES mDNS to DNS proxy components to enforce these selections. 

> In my opinion, there is not consensus in the WG to support your concern.

Really?

mDNS offers a secure basis for publishing RRset data in DNS?  It seems even
the requirements document warns against such use.

> The current text in the document represents WG consensus for the
> description of the potential problem.

The current text incorrectly assumes mDNS can safely be used to 
automatically publish addresses in DNS.  This is both wrong and unsafe.

> "example strategy [...] that MUST be supported" sounds like a mandate to me.

An ability to prefer one category of addressing over another is not a mandate
for any specific use.  It simply ensures support exists for secure methods for 
handling otherwise poorly vetted mDNS information.  These provisions can prevent
rampant abuse of a scheme based on unqualified UDP multicast announcements.

> This is a requirements document, not a final design, and therefore this
> document does not need to develop a solution to the problem you are
> concerned with.

It is also important reasonable _minimum_ requirements are established before
too much time and money is been spent heading in unsafe directions.

> the document to satisfy your concerns?

1)
Devices publishing addresses related to mDNS/DNS-SD should support configurations 
that prefer use of ULA addressing.  Per RFC7084, the role of the router is to prevent 
these addresses from going beyond or to have originated from the WAN interface.  
Similarly, when an ULA address is not present, similar configurations should support
similar preferences for RFC1918 addressing.

2)
The collection of DNS related information should also ensure header compliance
requirements as specified by RA Guard RFC7113.  This provision is to better ensure
administrative control of host naming conventions in lieu of IDNA naming restrictions.

Regards,
Douglas Otis

---

From: Douglas Otis <[email-masked]>
Date: Tue, 17 Mar 2015 16:03:52 -0700

Dear Ralph,

Really?

1)

2)

Regards,
Douglas Otis

---

From: Douglas Otis <[email-masked]>
Date: Wed, 18 Mar 2015 11:38:39 -0700

> On Mar 17, 2015, at 1:28 PM, Stephen Farrell <[email-masked]> wrote:
> 
> Signed PGP part
> 
> Hiya,
> 

Dear Stephen,

I have seen no consumer-level routers which offer IPv6 filtering, except 
in an “all-or-nothing” fashion, which makes sense given the practical 
limitations of memory and configuration.  Even high-end routers have no 
ability to track privacy extension IPv6 addresses, so no practical 
filtering methods currently exist.  That’s why it is so important to 
indicate in the draft that no routable address should be published in 
DNS without the active participation of the administrator.  Without this 
step, mDNS will publish routable addresses to devices which are not safe 
on the Internet, and can never be made safe.

It seems Tom described new infrastructure attempting to leverage mDNS as a 
method to update host resources in DNS.  There are many avenues permitting 
remote clients a means to query DNS information, where DNS-SD will not
secure this sensitive information.  When DNS contains IPv6 globally 
accessible addresses not practically blocked, distributing these addresses 
will expose devices that could be in a class of being permanently vulnerable 
to Internet access i.e. printers, baby monitors, infrastructure controls, etc.

Regards,
Douglas Otis

---

From: Douglas Otis <[email-masked]>
Date: Wed, 18 Mar 2015 11:38:39 -0700

Dear Stephen,

Regards,
Douglas Otis