Subject: [dnssd] draft-ietf-dnssd-requirements-00.txt: Requirements/Security Considerations

From: Daniel Migault <[email-masked]>
Date: Sun, 19 Jan 2014 09:02:03 +0100

Hi Folks,

Here are some additional requirements for
draft-ietf-dnssd-requirements-00.txt as well as a starting point for the
security consideration section. This section has been updated with Tim's
comments.

Your are more than welcome to comment/clarify/change the proposed text. We
would appreciate you provide them by Friday January 23 so they can be
considered for the next version.

Best Regards,

Daniel

*Terminology section:*

I think we should add the following terms. I am using used them in the
remaining of the mail. They may be changed for the draft.

mDNS: multicast DNS as defined in [RFC6762]
SSD: Scalable Service Discovery
SD DNS-Based Service Discovery [RFC6763]

*Requirements section:*

I suggest adding or complete existing requirements with the following ones:

SSD SHOULD be designed for both DNS and mDNS working in a cooperative way.
More specifically, it SHOULD consider interaction between DNS and mDNS.

SSD SHOULD be able to be performed by client only using DNS and unicast to
avoid multiple multicast messages.

SSD SHOULD work with existing DNS-Based Service Discovery over mDNS and
SHOULD NOT break any other discovery protocols.
As specified in the charter [http://datatracker.ietf.org/wg/dnssd/charter/]
"The WG will consider the tradeoffs between reusing/extending existing
protocols and developing entirely new ones. It is highly desirable
that any new solution is backwardly compatible with existing DNS-SD/mDNS
deployments. Any solution developed by the dnssd WG must not conflict
or interfere with the operation of other zero-configuration service and
naming protocols such as uPnP or LLMNR. Integration with such protocols
is out of scope for this WG."

and

"To document challenges and problems encountered in the coexistence
of zero configuration and global DNS name services in such
multi-link networks, including consideration of both the name
resolution mechanism and the namespace."

SSD SHOULD consider the use of globally unique FQDN that is specific of a
given network instead of a default domain name as ".local". SSD SHOULD
provide means to discover/announce the FQDN associated to the network. A
default and common FQDN - like ".local." could be used only when the
specific FQDN of the network has not been determined. Furthermore, in order
to ease interoperation with DNS the domain name SHOULD follow
DNS-compatible encoding (i.e ascii or punycode).

SSD SHOULD be able to take advantage of network configurations (DHCP/RA)
protocol. If it is clear that SSD and DNS SHOULD be able to work together,
DHCP may also be used to announce necessary information for the network
such as its associated FQDN (using DHCP Domain Search / DHCP Domain option
/ IPv6 RA [RFC6106]), the interface to register FQDNs... This MAY for
example complement or avoid the use of the specific
b/db/r/dr/lb.dns-sd._udp.<domain> or equivalent queries.

SSD SHOULD be able to announce the scope Service Discovery informations are
expected to be accessed or multicasted. This requires something like a
"scope" discovery protocol.

*Security Consideration section*

Here is some text I propose. Comments are more then welcome! I hope that we
will be able to fix this section during the next meeting.

1. Scalable DNS Service is not an extension of SD in term of security

Scalable DNS-Based Service Discovery can hardly rely on the security
considerations defined for DNS-Based Service Discovery [RFC6763].
Considering "Scalability" requires new security practices that are defines
in this document.

DNS-Based Service Discovery [RFC6763] has been designed so that a device
can announce a service to the other devices of the network. Although DNS or
mDNS can be used for SD, SD has been mostly thought to work over mDNS to
avoid DNS zone management and to handle UTF8 names for the end users even
in the domain part of the Instance Service Name. As a result SD' security
considerations rely on mDNS security considerations, DNSSEC [RFC4033] for
authentication and secure DNS update [RFC3007] to secure DNS update
[RFC2136]. These considerations are not sufficient for SSD as explained
below.

    - a) DNSSEC is probably the DNS extension that MAY be used to provide
authentication and integrity check protection. However, authentication
other than proof-of-ownership or leap-of-faith security model requires
trust anchors. Trust anchor MAY be provided by the global DNS, but this has
not been specified in SD. Section 10 of RFC6763 illustrates how to populate
the DNS with information but clearly states that such interactions are out
of scope of RFC6763. Interactions between SSD and DNS cannot be specified
in an illustrative section.

    - b) Similarly, DNS updates are used by SD to cooperate with DNS. These
interactions are left as illustrative in RFC6763, which is not sufficient
for SSD.

    -c) mDNS security considerations are not sufficient for SSD. At first,
mDNS requires cooperative devices. If cooperative devices is a reasonable
assumption in a one hop network such as most home networks, this assumption
cannot be made for larger networks, such as corporate networks for example.

       In case all devices cannot trust each other, SD considers the use of
IPsec or DNSSEC. How these protocols are used is not fully described in
RFC6762 and SHOULD be at least documented for SSD. More specifically,
DNSSEC can be used with different security models. Authentication of the
devices may require a chain of trust and interaction with DNS.
Alternatively authentication may rely on devices configured with
certificates. In the absence of such certificates or chain of trust, a
proof-of-ownership with device's reputation may be considered.

      mDNS considers the use of DNSSEC to differentiate responses from the
global DNS and mDNS that addresses a local scope. DNSSEC may not be the
appropriated solution for SSD as DNSSEC may not be deployed for the global
DNS or for mDNS which would make distinction impossible. As suggested by
RFC6761, the use of ".local" to specify mDNS may be more appropriated.

      mDNS also raises the issue of relative domain names (example.com)
that may be solved as example.com.local. or as example.com.search-domain.
This issue becomes more complex with SSD. For SD there is little ambiguity
with the meaning of ".local". It is a single link, usually a single
network. SSD considers multiple links and as such multiple ".local" and
multiple different search domain. Thus the question may be which link's
search domain is to be considered.

      mDNS considers very few interactions with DNS. The only mentioned
case is when a global DNS resolution is performed using mDNS. mDNS
indicates how to treat relative domains. Interaction between mDNS and DNS
was not so necessary as with one hop network there is a clear separation
between the local and non local (Internet) network. With multiple networks,
the frontier between local and non local becomes much undefined. As result
whether naming resolution is local (mDNS) or global (DNS) is not obvious.
This is why SSD needs to specify interactions between DNS and mDNS whereas
DNS-Based Service Discovery [RFC6763] does not. As a result security
considerations for SSD considers 1) security considerations of SSD over
mDNS, 2) security considerations of SSD over DNS and 3) security
considerations on interactions between DNS and mDNS.

As a result, security assumption of DNS-Based Service Discovery [RFC6763]
are not any more valid for Scalable DNS-Based Service Discovery.

1) Privacy protection

Information provided by SSD may contain private information that is not
expected to go outside  the specified scope.

Service Discovery carry information about the type of devices available in
your network, the software version, their location both physical like floor
as well as networking - like the IP address. All these pieces of
information may be useful for an intruder. Device and software information
are useful to identify vulnerabilities, and location information are useful
to locate the target, names may also include information that may be useful
to define a specific target - like "Personal CEO Printer". For these
reasons, one is willing to limit the scope these pieces of information.

    a) Informations spreading may be limited based on network information.
When DNS is used, the DNS zone SHOULD NOT be accessed by anyone from
outside the specific network. This can be performed at the DNS server level
or at the network boundaries by setting firewall policies specifying which
kind of IP address can access the DNS server. When mDNS is used,
multicasted information SHOULD NOT be forwarded outside the expected
network. This can be performed by firewalls that drops outbound/inbound
mDNS packets at the network boundaries. Note that in both cases, these
policies are outside the scope of mDNS or DNS. On the other hand, for
mobile devices, for example, which information may be provided depends on
the network. These policies have to be implemented by the mobile device.

    b) SSD SHOULD also consider scopes that are not correlated to network
definitions like 'building' or 'room'. As defined in the charter:
"It is also desirable that multiple discovery scopes are supported,
from the point of view of either performing discovery within a
specified scope or advertisement within a specified scope, and
being able to discover (enumerate) the set of scopes such that
an application could then choose to do either. It should be noted
that scope in this sense might refer to 'building' or 'room' and thus
might have no correlation to network topology."

This requires 1) definition of the different available scopes. Some default
value MAY be provided by the device without knowledge of the specific
available scopes of the network. Such default values MAY be used by devices
if they do not discover the different scopes specific to the network or if
the device does not have sufficient information to trust the announced
scopes. In that case the device MAY start with a default limited scope. 2)
Specific network values SHOULD be announced in an authenticated way to
avoid that, for example,  non existing scope used results in service
unavailable. The policy for non existing scopes SHOULD be defined with a
reduced scope, and the device SHOULD be informed that the scope does not
exist so it may update its scope. 3) Once devices have been informed of the
various scope, it MAY chose the one that seems the most appropriated and
provide this information. Depending on the scope, routers or middle boxes
MAY chose to forward the information or not. The information MAY be
forwarded on multiple links. With scopes that are not network correlated,
the information MAY be forwarded to a subset of devices within a link. The
use of distinct multicast IP address may be used to distinguish the
different scopes. However, the use of different IP addresses does not
prevent devices to listen to the information. If the device needs the
information to be read only by the members of the scope, cryptography MAY
be used to encrypt the data. IPsec multicast extension [RFC5374] may be a
good candidate. This mechanism may also be used to prevent an unauthorised
device to provide a service for a given scope. In other words, my printer
should not be able to announce its service for the "CEO" scope and I should
not be able to see the announcement of the printer of my CEO.

2) Exposing Services

A Service announced over a network does not mean the service is available
to anyone. Such services SHOULD enforce access control policies for the
service.

If a connected printer is not using SD, it MAY appear as a simple IP
connected device attached to the network. Only specific tests/scans/traffic
monitor can determine the device is a printer. When SD or SSD is used, as
soon as the device is plugged on the network everyone knows "Photo Color
Printer, Building A floor 2" has been plugged. If this printer is reserved
for the Graphic an Design department, than the printer SHOULD implement
access control mechanisms. Although these policies are out of scope of SSD,
they MAY be required as a consequence of SSD.

2) Resource exhaustion

With new emerging types of networks like sensor networks and more generally
the IoT, SSD cannot anymore rely on mDNS and multicast to advertise its
services and SHOULD provide a dedicated entity that can perform SSD via
unicast messages. Typically, this can be deployed with a mDNS-to-DNS agent
that receives announcement from mDNS devices and stores this information to
the DNS zone. Since the information is stored, other devices in the network
do not have to receive and treat mDNS announcements.

SSD MUST be able to scale to thousands of devices. The use of multicast for
service announcement requires that each device informs all other devices
some information like the hosted service for example. In order to make sure
devices always have the information up-to-date or that any new device has
the information, the device regularly retransmits the information to all
other devices. This is not a scalable architecture as it does not scale in
term of bandwidth nor it consider energy consumption constrains of small
devices.

Any messages are bytes received by the devices connected on the network,
which may require additional processing such as cryptographic check if used
in conjunction with DNSSEC for example. These devices may rely on battery,
and each of these messages directly impact the lifetime of the device. As a
result aggressive multicast may unnecessarily affect IoT devices. More
rational approach MAY consists in making possible SSD using unicast
communications only or to prevent that IoT device wakes up at every
multicast message or using multicast to announce information updates as
opposed to cache populating. More specifically, a new device can use
multicast to announce a newly published information. Eventually this
information may be cached by always-on devices and stored in the DNS. A new
device may get access to these pieces of information with an unicast AXFR
for example. The main advantage is that multicast interface can be switched
off.

So here we're in similar territory to the discussions about RAs, and
multicast on certain types of links, which has led to the efficient-ND
proposal, and related work on energy efficiency for low power devices etc. [
http://www.ietf.org/internet-drafts/draft-halpern-6man-nd-pre-resolve-addr-00.txt
]

3) Trusted Scalable Service Discovery

This section is only focused on how information provided by the SSD can be
trusted. As every device announce their service, SSD SHOULD prevent an
attacker to announce it is the "CEO Printer" in order to collect all
documents printed by the CEO.
In this section, we consider that "CEO Printer" does not exists and that
the attack does not aim at hijacking a specific name. Using the SD
terminology "CEO Printer" would be the Instance part of the Service
Instance Name.

a) User perspective
When DNS is used, DNSSEC can be used, and one can trust the information as
it provides from a trusted party. Although DNSSEC has not been designed as
a protocol that certifies the validity of the DNS RDATA, in our case,
DNSSEC could be used as such. Contrary to registrars that are hosting FQDNs
they have very few knowledge on, network administrators are expected to
administrated the DNS zone according to the resources available for the
network. As a result DNSSEC validation could be interpreted as "validated
by the administrator".

mDNS does not have trust anchors provided by DNSSEC. However, DNSSEC used
in conjunction of mDNS can be used to provide a proof-of-ownership of the
information. How reliable is that information can be learned over time by
processing the reputation of a device (represented by its public key) or by
monitoring whether the information remains coherent over time. For example,
if a printer announces its IP address as part of the company network, and
suddenly starts announcing an IP address located somewhere else, further
checks may be performed before trusting the information. Even though the
mDNS message signed with DNS cannot be trusted the same way as it would
have been trusted in a DNSSEC zone, using DNSSEC in conjunction of mDNS
makes possible to assign some pieces of information to a specific key. This
helps in establishing a reputation as well as avoids spoofed messages.

On a user perspective, mDNS requires the end user to establish a reputation
mechanism whereas DNS provides certified information. The main advantage of
DNS is that a new end user has certified information which is not possible
with mDNS.

[TBD check/compare hybrid model]

b) Devices perspective

When DNS is used, the device MUST be able to provide the information to the
DNS server via DNS update [RFC2136] or secure DNS update [RFC3007]. This
scenario may not meet a Zero configuration requirement as the DNS server
needs to know the public key of the devices, and the device needs to know
at least the IP address of the DNS server. If DHCPv6 the IP address of the
MAY be derived from the Domain Search List and the DNS Recursive Name
Server option [RFC3646]. The device MAY send a DNS query for one domain
search with type NS to the recursive name server. However, registering the
public keys of the devices in the DNS does not scale thousands of devices.
Most likely, their public keys may be considered as trusted based on
reputation, leap of faith principles which does not necessarily prevent an
attacker to set false data into the DNS zone.

When mDNS is used, the device does not need any configuration. This
information is announced to the network. The information will be trusted by
the devices that trust the announcer. As for the DNS, provisioning all
devices of the network with all public keys is not scalable. As mentioned
above, public keys will be trusted most likely based on reputation or leap
of faith principles.

The main difference between DNS and mDNS seems that DNS requires less
provisioning or configuration than mDNS (n versus n * (n - 1) for a n
device network). Then in a zero configuration scenario, DNS centralises in
a single point the way a key can be trusted. The only disadvantage of using
DNS is the devices should discover the DNS server.

It seems that approach combining mDNS and DNS can take advantage of both.
Devices announce information using mDNS and the DNS according to the level
of trust stores the information in its zone.

4) Information impersonation

The previous section provided considerations on how a device can be
associated to a public key and eventually identified as a trusted device.
With zero configuration, the level of trust associated to a device results
of a trade off between configuration and a learning process. This section
indicates how information provided by the devices can be monitored to
determine the reputation of a device, to raise an alarm to the
administrator, and eventually show a device cannot be trusted or indicate a
device has been  corrupted.

The kind of informations provided by SD or SSD that are visible to the end
user are 1) a name that describes a service and 2) the location of the
service. The name of the service corresponds to Service Instance Name. With
SD the name is mentioned in the RDATA part of the PTR and as the key of the
SRV RRSet. The location of the service is the RDATA part of the SRV as well
as its corresponding locator.

The Service Instance Name is composed of three parts: Instance, Service
Name and Domain. SD recommends that Instance and Domain are encoded using
UTF8. UTF8 enables specific characters that are not yet being considered in
the current DNS. Traditional DNS uses ascii or Punycode. If UTF8 is more
flexible in term of string representation, it may provide multiple ways to
express the same thing which may confuse the end user. In fact using UTF8
"My Printer", "my printer" "My printer" are different strings. This may be
used by an attacker that will provide a service different in term of UTF8
format, but that the end user will assimilate to the same service. In
addition, "my printer" will be displayed differently if encoded in UTF8 or
in ascii. As a result two service "my printer" could be stored in a DNS
zone without any collisions.
One way to avoid multiple format would be to consider the necessary or
missing characters provided by UTF8 and add them in the Puny code.
If there may be some advantages in using UTF8 for the service name, the
domain name part SHOULD use only the Punycode.
As a result, checking information for SSD requires to establish
metrics/similarities between strings.

Worth noting in the DNS the device might be hpprint01.bldg32.somesite.com,
while its internally stored label may be "Building 32 foyer printer".

The location of the service is identified by a FQDN and a corresponding IP
address. In SD, the FQDN respect the Punnycode encoding. The FQDN of the
service may be checked against the known domain names associated to the
network. Similarly, the IP address is generally used to locate the service.
if the IP address is not inside the network, this may raise a warning to
the administrator, that may validate the IP address.

When DNSSEC is used closed names addressed by different keys are
suspicious. Without the use of DNSSEC is becomes hard to detect the
device/SD device has not changed their IP address.

5) Unique network identifier

SD uses ".local" prefix to indicate the scope of the FQDN.  ".local" is a
special use domain name - RFC 6761, and in the registry at
http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml

".local" is instantiated in any networks. This results in a given string
with multiple meanings. "My Printer" at home is not the same service as "My
Printer" at work and if the information is cached in some devices, this may
result in cross site name hijacking. An attacker could for example
advertise "My Printer" in a public network like in an airport with a global
IP address. The Service Instance Name used could be something as "My
Printer_ipp_tcp.local SRV global-printer.example.com". People in the
airport may then send their documents to "My Printer" advertised in the
airport - that is to say global-printer.example.com -, instead of the one
of their office.

In order to mitigate this confusion, ".local" SHOULD be used only when the
device does not know the domain name associated to the network. If DHCPv6
is used this may be derived by the DHCPv6 Client FQDN option [RFC4704].

Note also that "My printer" may be a different printer when I am at home or
at work. On the other hand, while at hoe I SHOULD be able to use "My Office
Printer" and vice versa. This ambiguity may be leverage by the use of
unique prefix.

6) Compromised device

This section estimates how a compromised device impacts the SSD service. We
assume DNSSEC is used.

Once detected, the public key associated to the device is revoked. With DNS
the revocation occurs once in the DNS, and the information is only stored
in the remaining caches of devices that have requested the information
before it expires. After TTL seconds, the information is revoked from all
devices. If mDNS is used, revocation should occur in every device. The
mechanism to detect a device is compromised is complex and will probably
not be implemented properly in most devices.

With the current SD, a compromised device MAY provide wrong information
about itself but does not affect others device information.

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: "Guangqing Deng" <[email-masked]>
Date: Tue, 21 Jan 2014 15:54:09 +0800

Hi, Daniel, so many details on SSD requirements are presented here, which helps me have a more deep understanding on this issue. It is said that IPsec and DNSSEC can be used to authenticate the devices tending to provide service. While one question is that the deployment of IPsec and DNSSEC may lead to highly increased traffic within the local network. And for those temporary service providers (which just provide services in a short time in a mesh wireless network, for instance), the process of temporary service provider registering on DNSSEC system may be too long compared with the relatively short serving period. Also, the DNSSEC system has to revoke the public key of the temporary service provider if it has gone off-line. So it seems that we should clarify the service mentioned in this WG. Is the service mentioned in this WG means a long-term one or short-term one or both?

Guangqing Deng
CNNIC 

From: Daniel Migault
Date: 2014-01-19 16:02
To: dnssd
CC: Tim Chown; Kerry Lynn
Subject: [dnssd] draft-ietf-dnssd-requirements-00.txt: Requirements/Security Considerations
Hi Folks, 

Here are some additional requirements for  draft-ietf-dnssd-requirements-00.txt as well as a starting point for the security consideration section. This section has been updated with Tim's comments.

Your are more than welcome to comment/clarify/change the proposed text. We would appreciate you provide them by Friday January 23 so they can be considered for the next version.

Best Regards,

Daniel

Terminology section:

I think we should add the following terms. I am using used them in the remaining of the mail. They may be changed for the draft.

Requirements section:

SSD SHOULD be designed for both DNS and mDNS working in a cooperative way. More specifically, it SHOULD consider interaction between DNS and mDNS.

SSD SHOULD be able to be performed by client only using DNS and unicast to avoid multiple multicast messages.

SSD SHOULD work with existing DNS-Based Service Discovery over mDNS and SHOULD NOT break any other discovery protocols. 

and

SSD SHOULD consider the use of globally unique FQDN that is specific of a given network instead of a default domain name as ".local". SSD SHOULD provide means to discover/announce the FQDN associated to the network. A default and common FQDN - like ".local." could be used only when the specific FQDN of the network has not been determined. Furthermore, in order to ease interoperation with DNS the domain name SHOULD follow DNS-compatible encoding (i.e ascii or punycode).

SSD SHOULD be able to take advantage of network configurations (DHCP/RA) protocol. If it is clear that SSD and DNS SHOULD be able to work together, DHCP may also be used to announce necessary information for the network such as its associated FQDN (using DHCP Domain Search / DHCP Domain option / IPv6 RA [RFC6106]), the interface to register FQDNs... This MAY for example complement or avoid the use of the specific b/db/r/dr/lb.dns-sd._udp.<domain> or equivalent queries.  

SSD SHOULD be able to announce the scope Service Discovery informations are expected to be accessed or multicasted. This requires something like a "scope" discovery protocol.

Security Consideration section

Here is some text I propose. Comments are more then welcome! I hope that we will be able to fix this section during the next meeting.

Scalable DNS-Based Service Discovery can hardly rely on the security considerations defined for DNS-Based Service Discovery [RFC6763]. Considering "Scalability" requires new security practices that are defines in this document.

DNS-Based Service Discovery [RFC6763] has been designed so that a device can announce a service to the other devices of the network. Although DNS or mDNS can be used for SD, SD has been mostly thought to work over mDNS to avoid DNS zone management and to handle UTF8 names for the end users even in the domain part of the Instance Service Name. As a result SD' security considerations rely on mDNS security considerations, DNSSEC [RFC4033] for authentication and secure DNS update [RFC3007] to secure DNS update [RFC2136]. These considerations are not sufficient for SSD as explained below.

    - a) DNSSEC is probably the DNS extension that MAY be used to provide authentication and integrity check protection. However, authentication other than proof-of-ownership or leap-of-faith security model requires trust anchors. Trust anchor MAY be provided by the global DNS, but this has not been specified in SD. Section 10 of RFC6763 illustrates how to populate the DNS with information but clearly states that such interactions are out of scope of RFC6763. Interactions between SSD and DNS cannot be specified in an illustrative section.

    - b) Similarly, DNS updates are used by SD to cooperate with DNS. These interactions are left as illustrative in RFC6763, which is not sufficient for SSD.

    -c) mDNS security considerations are not sufficient for SSD. At first, mDNS requires cooperative devices. If cooperative devices is a reasonable assumption in a one hop network such as most home networks, this assumption cannot be made for larger networks, such as corporate networks for example. 

       In case all devices cannot trust each other, SD considers the use of IPsec or DNSSEC. How these protocols are used is not fully described in RFC6762 and SHOULD be at least documented for SSD. More specifically, DNSSEC can be used with different security models. Authentication of the devices may require a chain of trust and interaction with DNS. Alternatively authentication may rely on devices configured with certificates. In the absence of such certificates or chain of trust, a proof-of-ownership with device's reputation may be considered.  

      mDNS considers the use of DNSSEC to differentiate responses from the global DNS and mDNS that addresses a local scope. DNSSEC may not be the appropriated solution for SSD as DNSSEC may not be deployed for the global DNS or for mDNS which would make distinction impossible. As suggested by RFC6761, the use of ".local" to specify mDNS may be more appropriated. 

      mDNS also raises the issue of relative domain names (example.com) that may be solved as example.com.local. or as example.com.search-domain. This issue becomes more complex with SSD. For SD there is little ambiguity with the meaning of ".local". It is a single link, usually a single network. SSD considers multiple links and as such multiple ".local" and multiple different search domain. Thus the question may be which link's search domain is to be considered. 
    
      mDNS considers very few interactions with DNS. The only mentioned case is when a global DNS resolution is performed using mDNS. mDNS indicates how to treat relative domains. Interaction between mDNS and DNS was not so necessary as with one hop network there is a clear separation between the local and non local (Internet) network. With multiple networks, the frontier between local and non local becomes much undefined. As result whether naming resolution is local (mDNS) or global (DNS) is not obvious. This is why SSD needs to specify interactions between DNS and mDNS whereas DNS-Based Service Discovery [RFC6763] does not. As a result security considerations for SSD considers 1) security considerations of SSD over mDNS, 2) security considerations of SSD over DNS and 3) security considerations on interactions between DNS and mDNS.

As a result, security assumption of DNS-Based Service Discovery [RFC6763] are not any more valid for Scalable DNS-Based Service Discovery. 

1) Privacy protection

Information provided by SSD may contain private information that is not expected to go outside  the specified scope. 

Service Discovery carry information about the type of devices available in your network, the software version, their location both physical like floor as well as networking - like the IP address. All these pieces of information may be useful for an intruder. Device and software information are useful to identify vulnerabilities, and location information are useful to locate the target, names may also include information that may be useful to define a specific target - like "Personal CEO Printer". For these reasons, one is willing to limit the scope these pieces of information.

    a) Informations spreading may be limited based on network information. When DNS is used, the DNS zone SHOULD NOT be accessed by anyone from outside the specific network. This can be performed at the DNS server level or at the network boundaries by setting firewall policies specifying which kind of IP address can access the DNS server. When mDNS is used, multicasted information SHOULD NOT be forwarded outside the expected network. This can be performed by firewalls that drops outbound/inbound mDNS packets at the network boundaries. Note that in both cases, these policies are outside the scope of mDNS or DNS. On the other hand, for mobile devices, for example, which information may be provided depends on the network. These policies have to be implemented by the mobile device.

    b) SSD SHOULD also consider scopes that are not correlated to network definitions like 'building' or 'room'. As defined in the charter: 

This requires 1) definition of the different available scopes. Some default value MAY be provided by the device without knowledge of the specific available scopes of the network. Such default values MAY be used by devices if they do not discover the different scopes specific to the network or if the device does not have sufficient information to trust the announced scopes. In that case the device MAY start with a default limited scope. 2) Specific network values SHOULD be announced in an authenticated way to avoid that, for example,  non existing scope used results in service unavailable. The policy for non existing scopes SHOULD be defined with a reduced scope, and the device SHOULD be informed that the scope does not exist so it may update its scope. 3) Once devices have been informed of the various scope, it MAY chose the one that seems the most appropriated and provide this information. Depending on the scope, routers or middle boxes MAY chose to forward the information or not. The information MAY be forwarded on multiple links. With scopes that are not network correlated, the information MAY be forwarded to a subset of devices within a link. The use of distinct multicast IP address may be used to distinguish the different scopes. However, the use of different IP addresses does not prevent devices to listen to the information. If the device needs the information to be read only by the members of the scope, cryptography MAY be used to encrypt the data. IPsec multicast extension [RFC5374] may be a good candidate. This mechanism may also be used to prevent an unauthorised device to provide a service for a given scope. In other words, my printer should not be able to announce its service for the "CEO" scope and I should not be able to see the announcement of the printer of my CEO. 

2) Exposing Services

A Service announced over a network does not mean the service is available to anyone. Such services SHOULD enforce access control policies for the service.

If a connected printer is not using SD, it MAY appear as a simple IP connected device attached to the network. Only specific tests/scans/traffic monitor can determine the device is a printer. When SD or SSD is used, as soon as the device is plugged on the network everyone knows "Photo Color Printer, Building A floor 2" has been plugged. If this printer is reserved for the Graphic an Design department, than the printer SHOULD implement access control mechanisms. Although these policies are out of scope of SSD, they MAY be required as a consequence of SSD.
  
2) Resource exhaustion

With new emerging types of networks like sensor networks and more generally the IoT, SSD cannot anymore rely on mDNS and multicast to advertise its services and SHOULD provide a dedicated entity that can perform SSD via unicast messages. Typically, this can be deployed with a mDNS-to-DNS agent that receives announcement from mDNS devices and stores this information to the DNS zone. Since the information is stored, other devices in the network do not have to receive and treat mDNS announcements.

SSD MUST be able to scale to thousands of devices. The use of multicast for service announcement requires that each device informs all other devices some information like the hosted service for example. In order to make sure devices always have the information up-to-date or that any new device has the information, the device regularly retransmits the information to all other devices. This is not a scalable architecture as it does not scale in term of bandwidth nor it consider energy consumption constrains of small devices.

Any messages are bytes received by the devices connected on the network, which may require additional processing such as cryptographic check if used in conjunction with DNSSEC for example. These devices may rely on battery, and each of these messages directly impact the lifetime of the device. As a result aggressive multicast may unnecessarily affect IoT devices. More rational approach MAY consists in making possible SSD using unicast communications only or to prevent that IoT device wakes up at every multicast message or using multicast to announce information updates as opposed to cache populating. More specifically, a new device can use multicast to announce a newly published information. Eventually this information may be cached by always-on devices and stored in the DNS. A new device may get access to these pieces of information with an unicast AXFR for example. The main advantage is that multicast interface can be switched off.
 
So here we're in similar territory to the discussions about RAs, and multicast on certain types of links, which has led to the efficient-ND proposal, and related work on energy efficiency for low power devices etc. [http://www.ietf.org/internet-drafts/draft-halpern-6man-nd-pre-resolve-addr-00.txt]

This section is only focused on how information provided by the SSD can be trusted. As every device announce their service, SSD SHOULD prevent an attacker to announce it is the "CEO Printer" in order to collect all documents printed by the CEO. 
In this section, we consider that "CEO Printer" does not exists and that the attack does not aim at hijacking a specific name. Using the SD terminology "CEO Printer" would be the Instance part of the Service Instance Name.

a) User perspective
When DNS is used, DNSSEC can be used, and one can trust the information as it provides from a trusted party. Although DNSSEC has not been designed as a protocol that certifies the validity of the DNS RDATA, in our case, DNSSEC could be used as such. Contrary to registrars that are hosting FQDNs they have very few knowledge on, network administrators are expected to administrated the DNS zone according to the resources available for the network. As a result DNSSEC validation could be interpreted as "validated by the administrator".

mDNS does not have trust anchors provided by DNSSEC. However, DNSSEC used in conjunction of mDNS can be used to provide a proof-of-ownership of the information. How reliable is that information can be learned over time by processing the reputation of a device (represented by its public key) or by monitoring whether the information remains coherent over time. For example, if a printer announces its IP address as part of the company network, and suddenly starts announcing an IP address located somewhere else, further checks may be performed before trusting the information. Even though the mDNS message signed with DNS cannot be trusted the same way as it would have been trusted in a DNSSEC zone, using DNSSEC in conjunction of mDNS makes possible to assign some pieces of information to a specific key. This helps in establishing a reputation as well as avoids spoofed messages.

On a user perspective, mDNS requires the end user to establish a reputation mechanism whereas DNS provides certified information. The main advantage of DNS is that a new end user has certified information which is not possible with mDNS.

b) Devices perspective

When DNS is used, the device MUST be able to provide the information to the DNS server via DNS update [RFC2136] or secure DNS update [RFC3007]. This scenario may not meet a Zero configuration requirement as the DNS server needs to know the public key of the devices, and the device needs to know at least the IP address of the DNS server. If DHCPv6 the IP address of the MAY be derived from the Domain Search List and the DNS Recursive Name Server option [RFC3646]. The device MAY send a DNS query for one domain search with type NS to the recursive name server. However, registering the public keys of the devices in the DNS does not scale thousands of devices. Most likely, their public keys may be considered as trusted based on reputation, leap of faith principles which does not necessarily prevent an attacker to set false data into the DNS zone. 
   
When mDNS is used, the device does not need any configuration. This information is announced to the network. The information will be trusted by the devices that trust the announcer. As for the DNS, provisioning all devices of the network with all public keys is not scalable. As mentioned above, public keys will be trusted most likely based on reputation or leap of faith principles.

The main difference between DNS and mDNS seems that DNS requires less provisioning or configuration than mDNS (n versus n * (n - 1) for a n device network). Then in a zero configuration scenario, DNS centralises in a single point the way a key can be trusted. The only disadvantage of using DNS is the devices should discover the DNS server.

It seems that approach combining mDNS and DNS can take advantage of both. Devices announce information using mDNS and the DNS according to the level of trust stores the information in its zone.

The previous section provided considerations on how a device can be associated to a public key and eventually identified as a trusted device. With zero configuration, the level of trust associated to a device results of a trade off between configuration and a learning process. This section indicates how information provided by the devices can be monitored to determine the reputation of a device, to raise an alarm to the administrator, and eventually show a device cannot be trusted or indicate a device has been  corrupted.

The kind of informations provided by SD or SSD that are visible to the end user are 1) a name that describes a service and 2) the location of the service. The name of the service corresponds to Service Instance Name. With SD the name is mentioned in the RDATA part of the PTR and as the key of the SRV RRSet. The location of the service is the RDATA part of the SRV as well as its corresponding locator. 

The Service Instance Name is composed of three parts: Instance, Service Name and Domain. SD recommends that Instance and Domain are encoded using UTF8. UTF8 enables specific characters that are not yet being considered in the current DNS. Traditional DNS uses ascii or Punycode. If UTF8 is more flexible in term of string representation, it may provide multiple ways to express the same thing which may confuse the end user. In fact using UTF8 "My Printer", "my printer" "My printer" are different strings. This may be used by an attacker that will provide a service different in term of UTF8 format, but that the end user will assimilate to the same service. In addition, "my printer" will be displayed differently if encoded in UTF8 or in ascii. As a result two service "my printer" could be stored in a DNS zone without any collisions.
One way to avoid multiple format would be to consider the necessary or missing characters provided by UTF8 and add them in the Puny code.
If there may be some advantages in using UTF8 for the service name, the domain name part SHOULD use only the Punycode. 
As a result, checking information for SSD requires to establish metrics/similarities between strings.

Worth noting in the DNS the device might be hpprint01.bldg32.somesite.com, while its internally stored label may be "Building 32 foyer printer".

The location of the service is identified by a FQDN and a corresponding IP address. In SD, the FQDN respect the Punnycode encoding. The FQDN of the service may be checked against the known domain names associated to the network. Similarly, the IP address is generally used to locate the service. if the IP address is not inside the network, this may raise a warning to the administrator, that may validate the IP address.

When DNSSEC is used closed names addressed by different keys are suspicious. Without the use of DNSSEC is becomes hard to detect the device/SD device has not changed their IP address.

SD uses ".local" prefix to indicate the scope of the FQDN.  ".local" is a special use domain name - RFC 6761, and in the registry at
http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml

".local" is instantiated in any networks. This results in a given string with multiple meanings. "My Printer" at home is not the same service as "My Printer" at work and if the information is cached in some devices, this may result in cross site name hijacking. An attacker could for example advertise "My Printer" in a public network like in an airport with a global IP address. The Service Instance Name used could be something as "My Printer_ipp_tcp.local SRV global-printer.example.com". People in the airport may then send their documents to "My Printer" advertised in the airport - that is to say global-printer.example.com -, instead of the one of their office. 

In order to mitigate this confusion, ".local" SHOULD be used only when the device does not know the domain name associated to the network. If DHCPv6 is used this may be derived by the DHCPv6 Client FQDN option [RFC4704].

Note also that "My printer" may be a different printer when I am at home or at work. On the other hand, while at hoe I SHOULD be able to use "My Office Printer" and vice versa. This ambiguity may be leverage by the use of unique prefix.

6) Compromised device     

This section estimates how a compromised device impacts the SSD service. We assume DNSSEC is used.

Once detected, the public key associated to the device is revoked. With DNS the revocation occurs once in the DNS, and the information is only stored in the remaining caches of devices that have requested the information before it expires. After TTL seconds, the information is revoked from all devices. If mDNS is used, revocation should occur in every device. The mechanism to detect a device is compromised is complex and will probably not be implemented properly in most devices.

With the current SD, a compromised device MAY provide wrong information about itself but does not affect others device information.

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Daniel Migault <[email-masked]>
Date: Wed, 22 Jan 2014 07:55:56 +0100

Hi Deng,

Thank you very much for the comments and question. If I understand
correctly your point, you are saying that DNSSEC and IPsec performed
in an authenticated way may add to much overhead on the network for a
temporary service. This may be true on two aspects: 1) IPsec/DNSSEC
adds configurations, or equivalent mechanisms to have a trust anchor
2) DNSSEC /IPsec adds overheads (that is more bytes).

In the draft we are not really concerned about the service BUT service
discovery protocol. More specifically this means how you learn your
printer is at IP XXX using this configuration, not how you connect to
the printer.

To be honest I am not sure we have considered the specific service you
are referring to. Maybe you could specify briefly the service and
point out what would bother the service.

I guess the additional overhead depends on how long "temporary" is,
and to which frequency the service is up. I would be interested to
have more details on the service you are referring to.

What is not so clear to me is that security is the cause of the
problem. Maybe the problem of updating information is due to the DNS
format used to carry the service information. The DNS format imposes a
modification is efficient after TTL seconds which is the necessary
time all caches expires. During these TTL seconds, if not properly
considered, they may be some incoherent information about the service.
Again, a description of the service may clarify this.

The next paragraphs attempt to describe the overhead due to the use of
DNSSEC or IPsec.

With IPsec, devices could share a Certificate Authority or a specific
certificate. The service may be configured with this certificate which
would enable to authenticate to protect the mDNS/DNS transactions . Of
course it needs an initial configuration. IKEv2 adds a 4 packet
exchange over at least the first connection every connection. As a
result IKEv2 is the additional traffic.

With the use of DNSSEC as a certified database, each device / service
may need to register. Again, this may require the DNS to authenticate
the devices. keys associated to devices may be provisioned to the DNS
server.  Then SIG(0) can be used to authenticate the update of the
service. With DNSSEC you may have to remove security informations
(keys) in the DNS, but even without security you may had to remove the
connectivity inforlation (like IP addreses). As a result it does not
add additional exchanges, but makes message larger. If dnssd uses
mDNS, that is not a centralized database, then the use of DNSSEC does
not adds exchanges, but makes messages largers.

BR,
Daniel

BR
Daniel

On Tue, Jan 21, 2014 at 8:54 AM, Guangqing Deng <[email-masked]> wrote:
> Hi, Daniel, so many details on SSD requirements are presented here, which
> helps me have a more deep understanding on this issue. It is said that IPsec
> and DNSSEC can be used to authenticate the devices tending to provide
> service. While one question is that the deployment of IPsec and DNSSEC may
> lead to highly increased traffic within the local network. And for those
> temporary service providers (which just provide services in a short time in
> a mesh wireless network, for instance), the process of temporary service
> provider registering on DNSSEC system may be too long compared with the
> relatively short serving period. Also, the DNSSEC system has to revoke the
> public key of the temporary service provider if it has gone off-line. So it
> seems that we should clarify the service mentioned in this WG. Is the
> service mentioned in this WG means a long-term one or short-term one or
> both?
>
> ________________________________
> Guangqing Deng
> CNNIC
>
> From: Daniel Migault
> Date: 2014-01-19 16:02
> To: dnssd
> to ease interoperation with DNS the domain name SHOULD follow DNS-compatible
> encoding (i.e ascii or punycode).
>
>
> DHCP may also be used to announce necessary information for the network such
> as its associated FQDN (using DHCP Domain Search / DHCP Domain option / IPv6
> RA [RFC6106]), the interface to register FQDNs... This MAY for example
> complement or avoid the use of the specific
> DNS-Based Service Discovery [RFC6763] has been designed so that a device can
> announce a service to the other devices of the network. Although DNS or mDNS
> can be used for SD, SD has been mostly thought to work over mDNS to avoid
> DNS zone management and to handle UTF8 names for the end users even in the
> domain part of the Instance Service Name. As a result SD' security
> authentication and integrity check protection. However, authentication other
> than proof-of-ownership or leap-of-faith security model requires trust
> anchors. Trust anchor MAY be provided by the global DNS, but this has not
> been specified in SD. Section 10 of RFC6763 illustrates how to populate the
> DNS with information but clearly states that such interactions are out of
> scope of RFC6763. Interactions between SSD and DNS cannot be specified in an
> illustrative section.
>
> RFC6762 and SHOULD be at least documented for SSD. More specifically, DNSSEC
> can be used with different security models. Authentication of the devices
> may require a chain of trust and interaction with DNS. Alternatively
> authentication may rely on devices configured with certificates. In the
> absence of such certificates or chain of trust, a proof-of-ownership with
> device's reputation may be considered.
>
>       mDNS also raises the issue of relative domain names (example.com) that
> may be solved as example.com.local. or as example.com.search-domain. This
> issue becomes more complex with SSD. For SD there is little ambiguity with
> the meaning of ".local". It is a single link, usually a single network. SSD
> considers multiple links and as such multiple ".local" and multiple
> different search domain. Thus the question may be which link's search domain
> is to be considered.
>
>       mDNS considers very few interactions with DNS. The only mentioned case
> is when a global DNS resolution is performed using mDNS. mDNS indicates how
> to treat relative domains. Interaction between mDNS and DNS was not so
> necessary as with one hop network there is a clear separation between the
> local and non local (Internet) network. With multiple networks, the frontier
> between local and non local becomes much undefined. As result whether naming
> resolution is local (mDNS) or global (DNS) is not obvious. This is why SSD
> needs to specify interactions between DNS and mDNS whereas DNS-Based Service
> Discovery [RFC6763] does not. As a result security considerations for SSD
> considers 1) security considerations of SSD over mDNS, 2) security
> considerations of SSD over DNS and 3) security considerations on
> interactions between DNS and mDNS.
>
>
> as well as networking - like the IP address. All these pieces of information
> may be useful for an intruder. Device and software information are useful to
> identify vulnerabilities, and location information are useful to locate the
> target, names may also include information that may be useful to define a
> specific target - like "Personal CEO Printer". For these reasons, one is
> willing to limit the scope these pieces of information.
>
> When DNS is used, the DNS zone SHOULD NOT be accessed by anyone from outside
> the specific network. This can be performed at the DNS server level or at
> the network boundaries by setting firewall policies specifying which kind of
> IP address can access the DNS server. When mDNS is used, multicasted
> information SHOULD NOT be forwarded outside the expected network. This can
> be performed by firewalls that drops outbound/inbound mDNS packets at the
> network boundaries. Note that in both cases, these policies are outside the
> scope of mDNS or DNS. On the other hand, for mobile devices, for example,
> which information may be provided depends on the network. These policies
> have to be implemented by the mobile device.
>
> Specific network values SHOULD be announced in an authenticated way to avoid
> that, for example,  non existing scope used results in service unavailable.
> The policy for non existing scopes SHOULD be defined with a reduced scope,
> and the device SHOULD be informed that the scope does not exist so it may
> update its scope. 3) Once devices have been informed of the various scope,
> it MAY chose the one that seems the most appropriated and provide this
> information. Depending on the scope, routers or middle boxes MAY chose to
> forward the information or not. The information MAY be forwarded on multiple
> links. With scopes that are not network correlated, the information MAY be
> forwarded to a subset of devices within a link. The use of distinct
> multicast IP address may be used to distinguish the different scopes.
> However, the use of different IP addresses does not prevent devices to
> listen to the information. If the device needs the information to be read
> only by the members of the scope, cryptography MAY be used to encrypt the
> data. IPsec multicast extension [RFC5374] may be a good candidate. This
> mechanism may also be used to prevent an unauthorised device to provide a
> service for a given scope. In other words, my printer should not be able to
> announce its service for the "CEO" scope and I should not be able to see the
> announcement of the printer of my CEO.
>
> 2) Exposing Services
>
> A Service announced over a network does not mean the service is available to
> anyone. Such services SHOULD enforce access control policies for the
> service.
>
> proposal, and related work on energy efficiency for low power devices etc.
> [http://www.ietf.org/internet-drafts/draft-halpern-6man-nd-pre-resolve-addr-00.txt]
>
> In this section, we consider that "CEO Printer" does not exists and that the
> attack does not aim at hijacking a specific name. Using the SD terminology
> "CEO Printer" would be the Instance part of the Service Instance Name.
>
> a) User perspective
> it provides from a trusted party. Although DNSSEC has not been designed as a
> protocol that certifies the validity of the DNS RDATA, in our case, DNSSEC
> could be used as such. Contrary to registrars that are hosting FQDNs they
> have very few knowledge on, network administrators are expected to
> network. As a result DNSSEC validation could be interpreted as "validated by
> the administrator".
>
> mDNS does not have trust anchors provided by DNSSEC. However, DNSSEC used in
> conjunction of mDNS can be used to provide a proof-of-ownership of the
> mDNS message signed with DNS cannot be trusted the same way as it would have
> been trusted in a DNSSEC zone, using DNSSEC in conjunction of mDNS makes
> possible to assign some pieces of information to a specific key. This helps
> in establishing a reputation as well as avoids spoofed messages.
>
> needs to know the public key of the devices, and the device needs to know at
> least the IP address of the DNS server. If DHCPv6 the IP address of the MAY
> be derived from the Domain Search List and the DNS Recursive Name Server
> option [RFC3646]. The device MAY send a DNS query for one domain search with
> type NS to the recursive name server. However, registering the public keys
> of the devices in the DNS does not scale thousands of devices. Most likely,
> their public keys may be considered as trusted based on reputation, leap of
> faith principles which does not necessarily prevent an attacker to set false
> data into the DNS zone.
>
> provisioning or configuration than mDNS (n versus n * (n - 1) for a n device
> network). Then in a zero configuration scenario, DNS centralises in a single
> point the way a key can be trusted. The only disadvantage of using DNS is
> the devices should discover the DNS server.
>
> The Service Instance Name is composed of three parts: Instance, Service Name
> and Domain. SD recommends that Instance and Domain are encoded using UTF8.
> UTF8 enables specific characters that are not yet being considered in the
> current DNS. Traditional DNS uses ascii or Punycode. If UTF8 is more
> in ascii. As a result two service "my printer" could be stored in a DNS zone
> without any collisions.
> if the IP address is not inside the network, this may raise a warning to the
> administrator, that may validate the IP address.
>
>
> When DNSSEC is used closed names addressed by different keys are suspicious.
> Without the use of DNSSEC is becomes hard to detect the device/SD device has
> not changed their IP address.
>
>
> result in cross site name hijacking. An attacker could for example advertise
> "My Printer" in a public network like in an airport with a global IP
> address. The Service Instance Name used could be something as "My
> Printer_ipp_tcp.local SRV global-printer.example.com". People in the airport
> may then send their documents to "My Printer" advertised in the airport -
> that is to say global-printer.example.com -, instead of the one of their
> office.
>
> device does not know the domain name associated to the network. If DHCPv6 is
> used this may be derived by the DHCPv6 Client FQDN option [RFC4704].
>
> Printer" and vice versa. This ambiguity may be leverage by the use of unique
> prefix.
>
> 6) Compromised device
>
> the revocation occurs once in the DNS, and the information is only stored in
> the remaining caches of devices that have requested the information before
> it expires. After TTL seconds, the information is revoked from all devices.
> If mDNS is used, revocation should occur in every device. The mechanism to
> detect a device is compromised is complex and will probably not be
> implemented properly in most devices.
>

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: "Guangqing Deng" <[email-masked]>
Date: Thu, 23 Jan 2014 11:42:49 +0800

Hi, Daniel, three pieces of in-line comments beginning with [Guangqing Deng] are listed below, please refer to.

Guangqing Deng
CNNIC 

From: Daniel Migault
Date: 2014-01-22 14:55
To: Guangqing Deng
CC: dnssd
Subject: Re: [dnssd] draft-ietf-dnssd-requirements-00.txt: Requirements/Security Considerations
Hi Deng,

[Guangqing Deng] exactly.

[Guangqing Deng] you are right, but different kinds of services may call for different 
specific service discovery protocols and thus maybe different security requirements. For those so-called
temporary service, mDNS may be preferred; while for relatively stable service (such as printing service),
either mDNS or unicast DNS is OK. And DNSSEC is just available in  unicast DNS
but not mDNS at the moment, so the security requirement may be also different.

[Guangqing Deng] Fundamentally, only those relatively stable service is suitable to be discovered through DNS-based 
discovery protocol; while with the development of mobile Internet, some temporary service like file (including videos, music, images et al.) 
sharing becomes more and more popular especially in wireless mesh network like 802.11 network. For instance, one may hope
to share some images or documents to her/his colleagues through 802.11 network in a particular time period (from 9 am to 10 am, for instance)
during which all colleagues in the same company can download the files.  So, basicly, there may be two kinds of services in DNSSD WG, one may 
be called long term  service (or stable service?) and the other short term service (or temporary service?). The former means the service will be 
provided in a long time period and thus the frequency of registerring, updating and revoking the security credential is relatively low. And further some heavy weight 
security technologies such as IPsec and DNSSEC can be introduced without too much additional traffic. The latter means the service is just
provided in a short time period and thus this kind of service should be discovered and revoked in a timely fashion by the service discovery protocol proposed 
by this WG. In this circumstance, mDNS but not unicast DNS may be more preferred, which means that the corresponding security technologies can be used 
for discovering the short term service is different from that for long term service. So it seems that different kinds of services lead to different security technologies,
different additional traffic and thus maybe different security requirement, though both services can be represented by the service instance names with same format.
So maybe it is time to give a explicit defination to the so-called _service_ in this WG, but first we should determine which kinds of services is this WG interested in.
And I still do not have two more formal and clear definitions for these two kinds of services yet at the moment, though I am trying to.

BR,
Daniel

BR
Daniel

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
_______________________________________________
dnssd mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnssd

---

From: Daniel Migault <[email-masked]>
Date: Sun, 26 Jan 2014 20:58:02 +0100

Hi,

Thanks for the feed backs. We should definitely consider these
specific "volatile" services. I have added my comments in the text
body. I would be happy to know your thoughts and if it answers your
questions. Then we will check how to update the current text ;-)

BR,
Daniel

> are listed below, please refer to.
You are right. What I mean is that mDNS and DNS can use DNSSEC more or
less in the same way. However, use cases addressed by mDNS may miss
the chain of trust. As a result DNSSEC may be used only for
proof-of-owership. In some case this may be sufficient (especially for
long term services). But it is true that for "volatile" services, that
is service announced for a very short time once, the interests
provided by proof-of-ownership may be limited.

Let me know what you think of this text.

a) mDNS and DNS unicast as different DNS application transport protocols:

mDNS and DNS can be seen as two ways to provide DNS data, and in that
sense DNSSEC can be used by both DNS unicast and mDNS. DNSSEC RRsets
are DNSKEYS, SIG or NSEC/NSEC3 (although I would not consider
NSEC/NSEC3 at first). SIG binds the RRs signed to the key stored in
the DNSKEY RRset, thus providing integrity check, and
proof-of-ownership. To be able to say the DNSKEY is authoritative and
legitimate to announce the service the DNSKEY should be either a trust
anchor or signed by a trusted anchor. Being signed by a trust anchor
may require some interactions with a central entity which requires
additional process. Becoming a trust anchor may be done over time,
which of course suppose there is a long term establishment for the
service.

b) Proof-of-ownership may be sufficient:
Proof-of-ownership here means the entity claiming authority to the RR
also holds the private key associated to DNSSEY. This binding without
kind of certification is useful if a single device is expected to have
multiple interactions with the service discovery. (at least
broadcasting multiple messages with mDNS).

For example service S is announced at IP1, and latter due to
renumbering the same service is hosted at IP2. Using
proof-of-ownership indicates that the service is announced by the same
entity. If the mDNS message is sent by the service itself (like the
printer) it means the same printer has changed its IP address. Without
the DNSSEC RRsets, one would not have been able to determine whether
the service has changed its IP address or whether a new service is
being announced or the previous service is being hijacked.
If IP1 is re-announced using mDNS, then the bindings asserts that the
announcement comes from the same device.

Similarly if we combine mDNS and DNS with a mDNS agent that receives
mDNS messages and store them in a ".local" DNS unicast zone. Updating
the RRset via DNS updates requires a proof-of-ownership.

c) Proof-of ownership may not be sufficient

There are of course some cases where proof of ownership is not
sufficient. In fact proof-of-ownership does not assert the announcer
is legitimate. As a result certification may be required for both
devices that do not have a learning process of the trusted devices. On
the client side, this can be on small devices that do not implement
these process or new comer devices that do not have time to perform
the learning procedure. On the service side, one-time announcement for
"volatile" services do not provides the opportunity to be trusted.

First a new comer nodes will not be able to know a service is being
announced by the legitimate service. In that case, the new comer
device does not have the sufficient time to learn whose device is
legitimate.

> [Guangqing Deng] Fundamentally, only those relatively stable service is
> suitable to be discovered through DNS-based
> discovery protocol; while with the development of mobile Internet, some
> temporary service like file (including videos, music, images et al.)
> sharing becomes more and more popular especially in wireless mesh network
> like 802.11 network. For instance, one may hope
> to share some images or documents to her/his colleagues through 802.11
> network in a particular time period (from 9 am to 10 am, for instance)
> during which all colleagues in the same company can download the files.  So,
> basicly, there may be two kinds of services in DNSSD WG, one may
> be called long term  service (or stable service?) and the other short term
> service (or temporary service?). The former means the service will be
> provided in a long time period and thus the frequency of registerring,
> updating and revoking the security credential is relatively low. And further
> some heavy weight
> security technologies such as IPsec and DNSSEC can be introduced without too
> much additional traffic. The latter means the service is just
> provided in a short time period and thus this kind of service should be
> discovered and revoked in a timely fashion by the service discovery protocol
> proposed
> by this WG. In this circumstance, mDNS but not unicast DNS may be more
> preferred, which means that the corresponding security technologies can be
> used
> for discovering the short term service is different from that for long term
> service. So it seems that different kinds of services lead to different
> security technologies,
> different additional traffic and thus maybe different security requirement,
> though both services can be represented by the service instance names with
> same format.
> So maybe it is time to give a explicit defination to the so-called _service_
> in this WG, but first we should determine which kinds of services is this WG
> interested in.
> And I still do not have two more formal and clear definitions for these two
> kinds of services yet at the moment, though I am trying to.
>
>
To me there is no difference with DNS and mDNS.  Suppose a DNS listen
to the mDNS message and builds a ".local" zone the same a mDNS device
would do. As an end user, I will be to send a ".local" query to the
DNS, which avoids me to handle mDNS. The main advantage is that such
DNS is most likely always on and will be appropriated to define how a
device can be trusted over time. In a sense this DNS provides some
security features and can reduce the mDNS traffic. A service only
needs to announce the service every TTL as the DNS is always on, and
does not have to consider new incoming devices.
For a service available 1 hour, I would consider:
    - the service knows a DNS ".local" is associated to a mDNS agent:
the service broadcast a mDNS message with a short TTL and then rely on
the DNS for being discovered.  Once finished, it sends a mDNS update
with TTL set to 0. This lead to a service that may be cached TTL while
not available anymore. The other way around is to update directly the
DNS. In both cases it supposed client prefer the DNS as mDNS.
    - There is no DNS. In this case, I imagine more the case of mobile
phone in a undergrounds announcing service. An these service are
available for a few minutes to a few seconds. Suppose I am sharing
pictures, or videos. In such cases, it is not obvious you need to
authenticate the device, nor to trust it. As a result you may not need
to use DNSSEC or any kind of security. Proof-of-ownership may be
required to bind the service AND the Service discovery to a single
DNSKEY. (cf TLSA in dane). Th euse of key may also help differentiate
the different announced services.

Note that in both case, the device uses mDNS for announcing the
service. In the first case, the DNS keep this information which can be
accessed via DNS unicast. This avoids multiple mDNS announcements. In
the second case, because we are in a very opportunistic scenario, a
single mDNS announcement may be sufficient.  This makes announcement
easier for the devices. In the first case, end user may only be DNS
enable, whereas in second the end user must be mDNS enable.

So I agree scenarios may prefer DNS or mDNS, but for very
opportunistic scenarios, I still see some interests in using DNSSEC. I
agree that it mostly depends on the service and the environment (mDNS
agent, DNS present or not for the shared network).

>> Subject: [dnssd] draft-ietf-dnssd-requirements-00.txt:
>> Requirements/Security
>> Considerations
>> Hi Folks,
>>
>> As specified in the charter
>> [http://datatracker.ietf.org/wg/dnssd/charter/]
>> such
>> can
>> other
>> DNSSEC
>> that
>> case
>> information
>> outside
>> avoid
>> to
>> the
>> a
>> by
>> in
>> have
>> at
>> device
>> Name
>> the
>> suspicious.
>> advertise
>> airport
>> is
>> unique
>> in

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58