Subject: [dnssd] UTF8 use in DNS populated by mDNS

From: Douglas Otis <[email-masked]>
Date: Wed, 19 Nov 2014 16:50:39 -0800

Dear Dnssd Wg,

If UTF-8 is to be permitted in DNS populated using mDNS inputs, a superset of rules directly and indirectly established to support safe use of IDNA labels are necessary, otherwise omitting such requirements would permit trivial spoofing.  The requirements should include IDNA2008 considerations that restrict permitted code points.  It seems some advocate use of spaces in a domain name label be permitted.  Even this minor change may confuse users about the specific domain when seen with respect to commandline based applications.

Regards,
Douglas Otis

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 20 Nov 2014 17:11:51 -0500

Hi,

On Wed, Nov 19, 2014 at 04:50:39PM -0800, Douglas Otis wrote:
> If UTF-8 is to be permitted in DNS populated using mDNS inputs, a
> superset of rules directly and indirectly established to support
> safe use of IDNA labels are necessary, otherwise omitting such
> requirements would permit trivial spoofing.  The requirements should
> include IDNA2008 considerations that restrict permitted code points.

In which part of the DNS-SD name do you want these restrictions?  I
think there is considerable discussion of the different parts of those
names in the draft I discussed in Honolulu.

Note that there is _already_ a standard for putting "UTF-8 labels" in
the DNS (going back to STD 13 and reiterated by RFC 2181).  In effect,
they're not "UTF-8 labels" but rather series of octets.

> It seems some advocate use of spaces in a domain name label be
> permitted.  Even this minor change may confuse users about the
> specific domain when seen with respect to commandline based
> applications.

This is already permitted, of course, just like anything else in
labels.

But as I guess is plain from my work on the mdns-dns compatibility
I-D, I do think there is a long-term problem here, which is why I
recommend the minimal interoperable subset.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 21 Nov 2014 16:42:18 +0100

> On 20 nov 2014, at 23:11, Andrew Sullivan <[email-masked]> wrote:
> 

FWIW I agree. One either have to add some kind of restriction on Unicode Codepoints or not, and if you start to go down the path of choosing code points (including normalization forms to use etc) that also impacts matching, then you have something much more complicated than what DNSSD was intended to do (according to my view).

So, I can not personally recommend any more work be done regarding specification on Unicode and DNSSD unless there are very compelling arguments on what problems there are to solve and why.

   Patrik

---

From: Douglas Otis <[email-masked]>
Date: Fri, 21 Nov 2014 18:29:12 -0800

> they're not "UTF-8 labels" but rather series of octets.

Dear Andrew,

DNS-SD generates:
'Service Instance Name = <Instance> . <Service> . <Domain>'

While there are restrictions on code points that define 'Instance' per RFC5198 with an additional stipulation not to include values between 0x00-0x1F and 0x7F, how the 'Domain' portion is determined is far less clear.  This is a concern when derived from easily spoofed multicast mDNS responses.  It is important a visual selection process does its best to preclude trivial domain spoofing which might resolve malicious sources.  

> recommend the minimal interoperable subset.

The concern is specifically with visually deceptive resources.  Limitations on what is allowed should ensure against abuse of right-to-left and left-to-right issues for example.  Some TLDs protect users with additional rules enforced by registrars that extend beyond those imposed by IDNA2008.  Allowing naive UTF-8 publication of mDNS resources into DNS without conversion to A-labels permitted for DNS suggests there will be an even greater need to qualify what appears to be external actually resides within the Internet.  A step facilitated by imposing use of ugly A-labels within local publication should also better guard against cache abuse as well.

Regards,
Douglas Otis

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 24 Nov 2014 11:43:34 -0500

Hi,

> 'Service Instance Name = <Instance> . <Service> . <Domain>'

Yes.

> While there are restrictions on code points that define 'Instance' per RFC5198 with an additional stipulation not to include values between 0x00-0x1F and 0x7F

Yes.

> , how the 'Domain' portion is determined is far less clear.  

No.

If you read RFC 6763 carefully, you will note that the Domain portion
is also restricted to RFC 5198, which is approximately UTF-8 in NFC.

> This is a concern when derived from easily spoofed multicast mDNS responses.  It is important a visual selection process does its best to preclude trivial domain spoofing which might resolve malicious sources.  
> 

If what you're attempting to do is prescribe, in the output of this
WG, general rules for "anti-phishing" for domain names, I am going to
resist the creation of such rules by this WG.  The WG doesn't have the
requisite expertise to do that, and DNSOP is an already-existing WG
that has a possibly relevant charter (though unfortunately almost
certainly inadequate clue about the relevant i18n issues). 
 
> The concern is specifically with visually deceptive resources.  Limitations on what is allowed should ensure against abuse of right-to-left and left-to-right issues for example.

LTR and RTL issues have remarkably little to do with phishing except
in some quite specific circumstances, and in those cases it is
_imposible_ for an application to cope with the edge case in
general, because of the distributed operation of the DNS.

>  Some TLDs protect users with additional rules enforced by registrars that extend beyond those imposed by IDNA2008.  

Yes.  That's registration policy and it is way beyond the capability
of this WG to create in a perfectly general way.

> Allowing naive UTF-8 publication of mDNS resources into DNS without conversion to A-labels permitted for DNS suggests there will be an even greater need to qualify what appears to be external actually resides within the Internet.

No.  As Dave Thaler argued quite clearly in Honolulu, you can have all
the phishing problems you want using either IDNA2008 or plain UTF-8
labels.  These are totally orthoganal problems.

>  A step facilitated by imposing use of ugly A-labels within local publication should also better guard against cache abuse as well.
> 

How?

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Mon, 24 Nov 2014 18:25:02 -0800

> is also restricted to RFC 5198, which is approximately UTF-8 in NFC.

It does not clearly defined where this string is obtained however, and RFC5198 offers scant protection from trivially spoofed domains. 

> certainly inadequate clue about the relevant i18n issues). 

If so, a logical approach would be to specify rules currently defined for domains permitted by registrars using IDNA2008.  Unless otherwise constrained by manual lists, this will still represent a difficult albeit vital check.  

> general, because of the distributed operation of the DNS.

Strongly disagree. Some type of TLD restriction MUST be imposed to prevent rampant abuse.  This might mean only allowing domains found in the search domain list, or those defined for local networks.  

> of this WG to create in a perfectly general way.

Being defined in the search list, or resolved within the Internet after conversion to A-Label form is well within the WG's ability. 

> labels.  These are totally orthoganal problems.

Again strongly disagree.  Only when there is a way to constrain the domains administrators may wish to permit, the there is no limit on the level of very nasty spoofing techniques possible.  Leaving this open to any domain permitted by RFC5198 makes controlling this issue fairly impractical.

>> A step facilitated by imposing use of ugly A-labels within local publication should also better guard against cache abuse as well.

By constraining the range of domains local DNS is expected to handle prevents trivial exploits that may also overwhelm local storage.  Such an impact might defeat TOFU methods for example.

Regards,
Douglas Otis