Subject: [dnssd] Review of draft-ietf-dnssd-mdns-dns-interop-01

From: "Hosnieh Rafiee" <[email-masked]>
Date: Wed, 22 Jul 2015 07:43:21 +0200

Hello,

I reviewed this draft. to be clear, I am not expert in unicode or
internationalized charactersets. My comments are as followings:

I think there is attack on the interopration of mDNS and unicast DNS and I
think applicable to this draft while in the security consideration, it is
not mentioned any mitigation mechanism.

- mixing mDNS and unicast DNS names
poor implementation might allow an attacker to response to unicast DNS query
request sent by a client for the purpose of resolving a global domain name.

If the mDNS requests are prioterize, there is a possibility that the client
accepts the mDNS response and prioterize it over unicast DNS names.
Therefore, the attacker has a chance to offer a fake response . The risk of
this attack is higher when the internationalized character set is allowed in
unicast DNS server. 

The possible mitigation is authentication of a service as well as the
unicast DNS

Now the question is that is it possible also to cheat the recursive resolver
with mDNS responses while looking up for a domain?

If the priority for looking up names is first unicast DNS and then mDNS,
then in this case there might be a lot of traffic to unicast DNS servers and
if it is the other round, then there might be the possibility of the attack
mentioned above

mitigation: authentication of recursive resolver

- section 3
<snip> U-labels cannot contain upper case letters </snip>

For some languages, upper case letter does not make it different specially
in some letters. Especially the languages that a word is the result of
attaching the characters together.  I think this is specially true for
non-european languages. Two examples are  Persian or Arabic.

Therefore, one cannot differentiate between mDNS service and DNS names with
only considering that DNS cannot use uppercase U-labels.

- section 4.2
It is not the requirement of DNSSD to use underscoll character, as far as I
can see it is only recommendation. please see
https://tools.ietf.org/html/rfc6763#section-7
Therefore, the attacker can use the similar domain names as unicast DNS for
its fake service which might result in confusion of the recursive DNS
servers 

Thanks,
Best,
Hosnieh

> -----Original Message-----
> From: dnssd [mailto:[email-masked]] On Behalf Of Ralph Droms
> (rdroms)
> Sent: Tuesday, July 21, 2015 10:06 AM
> To: [email-masked]
> Subject: [dnssd] Requesting review of draft-ietf-dnssd-mdns-dns-interop-01
> 
> Hi - The dnssd chairs would like to get some reviews of
draft-ietf-dnssd-mdns-
> dns-interop-01, "On Interoperation of Labels Between mDNS and DNS," from
> dnsop participants.  draft-ietf-dnssd-mdns-dns-interop-01 is currently in
dnssd
> WG last call and last call comments will be discussed in the dnssd WG
meeting
> this week.
> 
> Please post your feedback to dnsop or send to Tim and myself.
> 
> - Ralph
> 
> Bcc: [email-masked]
>

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 22 Jul 2015 10:36:05 +0200

Hi,

> - mixing mDNS and unicast DNS names

[…]

> with mDNS responses while looking up for a domain?

No.  As I said in the WG session, the way that mDNS and DNS
differentiate is using an in-band signalling mechanism, which is the
final non-null label of the QNAME.  If that last non-null label is
local, then it's mDNS; otherwise, it isn't.  If mDNS is responding to
DNS queries, then it's just not following the mDNS protocol.

> only considering that DNS cannot use uppercase U-labels.

Indeed, you cannot, and the document does not suggest you use this
mechanism to tell whether something is a DNS name, right?  

> can see it is only recommendation.

I don't see how.  The text you cite starts thus:

   The <Service> portion of a Service Instance Name consists of a pair
   of DNS labels, following the convention already established for SRV
   records [RFC2782].

   The first label of the pair is an underscore character followed by
   the Service Name [RFC6335].  The Service Name identifies what the
   service does and what application protocol it uses to do it.

The underscore character is in fact part of the definition, and is the
only way AFAICT that you'd be able to tell which part of the owner
name is the <Service> portion of a Service Instance Name.  

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Wed, 22 Jul 2015 10:51:02 +0200

Hi Andrew,

> 
> […]
> 
> > Now the question is that is it possible also to cheat the recursive
> > resolver with mDNS responses while looking up for a domain?
> 
> No.  As I said in the WG session, the way that mDNS and DNS differentiate is
> using an in-band signalling mechanism, which is the final non-null label of the
> QNAME.  If that last non-null label is local, then it's mDNS; otherwise, it isn't.  If
> mDNS is responding to DNS queries, then it's just not following the mDNS
> protocol.
> 
> > - section 3
> > For some languages, upper case letter does not make it different
> > specially in some letters. Especially the languages that a word is the
> > result of attaching the characters together.  I think this is
> > specially true for non-european languages. Two examples are  Persian or
> Arabic.
> >
> > Therefore, one cannot differentiate between mDNS service and DNS names
> > with only considering that DNS cannot use uppercase U-labels.
> 

True

> > - section 4.2
> > It is not the requirement of DNSSD to use underscoll character, as far
> > as I can see it is only recommendation.
> 

This part which says its is not a requirement of SRV records in general. What I understand is that following this structure is not the requirements. They are free to specify their namings

<snip>
Note that this usage of the "_udp" label for all protocols other than
   TCP applies exclusively to DNS-SD service advertising, i.e., services
   advertised using the PTR+SRV+TXT convention specified in this
   document.  It is not a requirement of SRV records in general.  Other
   specifications that are independent of DNS-SD and not intended to
   interoperate with DNS-SD records are not in any way constrained by
   how DNS-SD works just because they also use the DNS SRV record
   datatype [RFC2782]; they are free to specify their own naming
   conventions as appropriate.
</snip>
> The underscore character is in fact part of the definition, and is the only way
> AFAICT that you'd be able to tell which part of the owner name is the
> <Service> portion of a Service Instance Name.
> 
> Best regards,
> 

Thanks,
Best,
Hosnieh

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 22 Jul 2015 12:06:04 +0200

> This part which says its is not a requirement of SRV records in general. What I understand is that following this structure is not the requirements. They are free to specify their namings

I think you have it backwards.  I believe the text you cite is saying
that DNS-SD is not making normative rules for all SRV records, just
for ones in use for DNS-SD.

A

-- 
Andrew Sullivan
[email-masked]