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

[Douglas Otis <[e-mail]>]

On Nov 24, 2014, at 8:43 AM, Andrew Sullivan <[e-mail]> wrote:

> Hi,
> 
> On Fri, Nov 21, 2014 at 06:29:12PM -0800, Douglas Otis wrote:
>> Dear Andrew,
>> 
>> DNS-SD generates:
>> '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.

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

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

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.  

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

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.  

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

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

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

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.
>  
> How?

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