Re: [dnssd] Any review of Threat model?

[Hosnieh Rafiee <[e-mail]>]

Hi again,

On 04/04/2016 10:09 PM, Andrew Sullivan wrote:
>
> I'm trying to understand what the threat is from a practical point of
> view.  For instance, there is a claim in the draft about exfiltration.
> The truth is that, if you're running split-horizon DNS, you _already_
> have this problem.  Therefore, the risk is at worst that there are
> more queries that contain such leaks.  I don't know whether that's
> worse, but I confess I'm pretty sceptical; but those kinds of
> considerations need to be laid out.
>
> It simply isn't true that we just list the threats.  We try to lay out
> the threats, their severity, the liklihood that they'll happen, and so
> on.  Listing all the threats in the world would not be useful.
The threat is the scope of discovery where causes the services to be 
available to unwanted domains and most part of this draft emphasis on 
these kinds of threats.  of course it has different consequences and 
what we actually added to draft as I also explained in private chat in 
meetecho, is that we have to restrict the scope of discovery for some 
services specially in .home and homenet.
You explained that people would like their home fileservers to be 
available over the internet and it doesn't matter whether or not we add 
it to global DNS. But I quite disagree with you because when it is 
exposed on global DNS server, it can go beyond even the wanted scope 
that might be defined on edge routers because normally the DNS queries 
are not filtered on the network edge devices because of enabling clients 
to use DNS services or enabling outsiders to query the names on global 
DNS servers inside their networks and map names. That means, any 
external attacker can also query this global DNS server and can retreive 
the name of services.

Our most emphasis was on homenet services. that means the global DNS 
server for homenet is somewhere on ISPs and not inside the enterprise. 
That means all the users of that ISPs can access the services of other 
users in that ISPs as well as external people.... This is a huge 
security and privacy risks that it appears that it is easily neglected 
here.

Since, for example, IPv6, unfortunately the ULA is not used for services 
and services already receive the global IP address, that means, services 
are accessibile easily to external scope with publishing their names on 
global DNS server. In other word, it is not only your fileserver that is 
available to you over global DNS server but also to anyone else in the 
world. This is why in draft we clearly said that .home domains (that are 
on going discussion in homenet groups) should be restricted to use 
global DNS server.


Also There need to be restriction on the use of Global IP addresses and 
instead we use Unique local addresses that are by default not routable 
over the network and the admin needs to define rules on routers to route 
them.... This provide a bit of restriction and a bit of security and 
privacy for exposing services to unwanted domains. This is also what we 
have confirmed in the draft that unfortunately there was not time to 
discuss about them.

and of course a few sections of the draft discussed about the existing 
attacks that the global DNS can causes on DNSSD services.


>>   2.1.2.1  threat relates to defining a critical service when look-alike name
>> detection becomes problematic.
>>   Unlike DNS, mDNS assumes visual selection IDNA and/or raw UTF-8 allows for
>> many possible representations of the same visual representation.  By
>> allowing all the different representations allowed, this allows look alike
>> names. this is why IDNA should be limited for mDNS because there might be
>> different services with look alike names that cannot be easily determined.
> I'm sorry, but this is just false.  First, the problem already exists
> with plain LDH, because of l and 1.  Second, you can trivially
> recreate these problems in IDNA2008 -- Latin-A and Cyrillic-A are the
> usual example, but there are many such cases all of which are legal in
> IDNA.  "Look alike names" are a problem now, with the existing DNS-SD
> specification and with other cases (like following links).  All of the
> rules to solve that -- using mDNS or DNS or YourNewResolutionProtocol
> -- need to have these things handled by policy.  If the only point is,
> "Some policy controls are needed here," say that.  But either this is
> no more of an issue than any other i18n issue on the Internet, or else
> there is something peculiar about this case that makes it more of an
> issue.  There's been no effort AFAICT to show that the "more of an
> issue" case is what is going on here.
You can, of course, define it as policy.  In my understanding, this 
policy is a  part of the protocol and the restrictions that assigned now 
as a definition of using such capacity for DNSSD protocol. In other 
word, the possible problems arises on DNSSD services by using variety of 
look alike names that need to be take into consideration that at the 
moment it is not.

> Best regards,
>
> A
>
Best,
Hosnieh