Subject: [dnssd] Any review of Threat model?

From: Hosnieh Rafiee <[email-masked]>
Date: Sat, 2 Apr 2016 17:17:26 +0200

Folks,

Would you please take a look on the latest version of threat model
https://tools.ietf.org/html/draft-otis-dnssd-scalable-dns-sd-threats-03

Please let me know what else you want to see in the draft or whether the 
current version address the concerns mentioned in the last IETF
(minutes here : 
https://www.ietf.org/proceedings/94/minutes/minutes-94-dnssd )

Thanks,
Best,
Hosnieh

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 4 Apr 2016 15:13:09 -0400

Hi,

> https://tools.ietf.org/html/draft-otis-dnssd-scalable-dns-sd-threats-03

I have (at last, apologies for the delay) read this version of the draft.

It's with some distress I say I'm frustrated by this draft, because in
my reading it treats as similar kinds of problems issues that are
vastly different.  At the same time, it isn't clear whether the
document is just attempting to outline what the threats are, or
whether it is trying to prescribe what should happen as a result.  I
think for it to be useful, it still needs an enormous amount of work

    Confusing treatment

Different issues all seem to be treated as "threats" without any way
of telling who is threatened, how, or how severely.

For instance, the issue in 2.1.2.1 is really about user interface.
There are for sure problems with this sort of visual spoofing on the
Internet.  Yet the entire problem of i18n and visual confusability and
so on has literally nothing to do with whether you use IDNA or raw
UTF-8 in the DNS, so that discussion is just a red herring.  The basic
problem is that users can be phished.  If there is an argument here
for why DNS-SD is somehow different in this than everything else on
the Internet, I am unable to detect it.  Moreover, the issue is mixed
in to discussion in section 2.2 as well, where its relevance to
exfiltration is at best unclear.

The issue in 2.1.4, by contrast, is basically an argument that devices
that already rely on security by obscurity need to remain obscure.  I
suppose that's true, but the proposed solution basically just says,
"This feature that we desire shouldn't ever work."  That seems to
operate at an entirely different level than the i18n issues.  Again,
this security-by-obscurity issue reappears in 2.2, where I guess
exfiltration comes up again; I think this is probably the
split-horizon discussion, but it's not that clear.

Yet a different kind of issue -- the side effects of amplification --
are in section 2.3.  This is a generic issue with the DNS and
increasing sizes of RRsets.  It is undoubtedly an issue, but it's far
from plain to me that the explanation here covers the way the issues
play out on the Internet.

The discussion in 3.2 about data integrity after publication as
opposed to the correctness of the data at source is treated as an
"Authorization Issue".  It isn't clear that it is; and this is anyway
a systemic problem with the DNS, so it isn't clear how this is a
special threat case.

    What is the document for?

In general, I find the document confusing, hard to follow, and not
terribly consistent about whether it is reporting threats, or telling
you what you're supposed to do in reaction.  This ambiguity makes the
document in some places contentious when it needn't be, since the
problem described might well be accurate while the proposed solution
is not one with which we'd all agree.  As noted above, for instance,
the very title of 2.1.4 basically undermines one of the obvious use
cases for this protocol, so there's no way that everyone will accept
the advice.  

    What I would do if I wanted this document badly enough

If I were the authors, I'd reorganize the draft.  It seems to me there
are several different kinds of threat here.  One kind is threats that
are inherited by virtue of the kind of system in use.  So, you get the
threat of someone taking over the global DNS registration for a name
because you're using DNS.  Another kind is threats that are not really
new, but that are potentially made more easily available due to
DNS-SD, such as so-called "internal" hosts that get their names more
widely exposed in a split DNS scenario.  Another kind is threats that
are entirely new as a result of this technology.  (If there are any of
these in the document, I dont think I understand that.)

Optionally, and only if the WG wants it, one might then have a section
that lists various mitigation strategies for each of the threats.
Some threats will not be mitigable when using the technology, and the
only mitigation is, "Don't do that."  Others might be mitigable by
this or that action.

I hope these remarks are useful.  I'm sorry it's taken me so long to
get them out.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Hosnieh Rafiee <[email-masked]>
Date: Mon, 4 Apr 2016 21:47:31 +0200

Hi Andrew,

Thanks for your comments. mine is inline.

> of telling who is threatened, how, or how severely.
I am a bit confused with your sentence. I might be wrong, but usually we 
only specify what are the possible problems or threats but we do not 
care who is the attacker. we just identify the holes in the protocol but 
not who will use this hole to attack the system... so I am not sure what 
or who you wanted to see.
> exfiltration is at best unclear.
  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.
> cases for this protocol, so there's no way that everyone will accept
There were some sections in the draft that only focused on threats and a 
few sections that explains the available mechanisms that DNSSD can use 
to avoid such threats. But of course as you suggested and you think it 
is not clear what threats are new and what threats are not new, we can 
re-arrange the document separate these sections with different titles.
Best,
Hosnieh

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 4 Apr 2016 16:09:42 -0400

Hi,

> only specify what are the possible problems or threats but we do not care
> who is the attacker. we just identify the holes in the protocol but not who
> will use this hole to attack the system... so I am not sure what or who you
> wanted to see.

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.

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

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Hosnieh Rafiee <[email-masked]>
Date: Mon, 4 Apr 2016 22:44:16 +0200

Hi again,

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

> 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,
Hosnieh

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 4 Apr 2016 17:58:37 -0400

Hi,

On Mon, Apr 04, 2016 at 10:44:16PM +0200, Hosnieh Rafiee wrote:

> available to unwanted domains and most part of this draft emphasis on these
> kinds of threats.

So, then, two things:

    1.  DNS-SD does not in fact do anything at all to make the
    services available on the Internet.  They're already available.

    2.  It sounds like your document is better described as,
    "Consequences of exposing previously-unannounced services via
    DNS-SD".  If that's what you're trying to do, then making that
    scope crystal clear at the beginning (like for instance, in the
    abstract) would be good.

I still believe the document would benefit from really signficant
reorganization, but at least making its goal way clearer would help.

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

So, DNS-SD is about service discovery.  So it's not too surprising
that services that are already available are easier to discover when
DNS-SD is in use.  That actually does strike me as a potentially
useful point to make.

> Our most emphasis was on homenet services. that means the global DNS server
> for homenet is somewhere on ISPs and not inside the enterprise.

Or in the house, or whatever. AFAIK, HOMENET hasn't even established
the architecture for this yet.

> all the users of that ISPs can access the services of other users in that
> ISPs as well as external people.

That doesn't follow at all.  There are _lots_ of named services in my
home net that you can't access, because if you try I'll drop your
packets at the edge of my network.  Merely knowing the name of
something does not guarantee access.

Now, knowing the name of something _is_ knowing something that
previously one might not have known about.  And if the thing is
unsecured, it is of course accessible too.  Given that the whole point
is remote access, however, I can't see how the right answer to that
is, "Don't permit service discovery."  The _whole point_ is service
discovery.

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

Well, yes.  Of course.  Presumably this is what authentication and
authorization is for.

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

This is a completely different issue, unrelated to any of the above.
(A globally-ambiguous name akin to RFC 1918 addresses is not obviously
a good idea anyway, but regardless its functioning in the global DNS
is bound to be obscure.)

> You can, of course, define it as policy.  In my understanding, this policy
> is a  part of the protocol

I think your understanding is quite mistaken.  There is nothing in
IDNA to prevent a single label having in it "a" (U+0061) and "а"
(U+0430).  They're both PVALD.  I know of no consumer-grade software
in the world that doesn't use the very same bits on the screen to
render those two characters.  They're as confusable as can possibly
be, and there is nothing whatsoever in any protocol to prevent them
being used in a way that is possibly confusing to users.

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

So, andrews-laptop.local. and аndrews-laptop.local exhibit this
problem, I agree.  (The second of those has the Cyrillic "a" in it.)

Certainly, anvilwalrusden.com and аnvilwalrusden.com have the same
problem.  (Again, second one is Cyrillic --
xn--nvilwalrusden-v1k.com).  Fortunately for us, Verisign doesn't
permit domain names of the second form (because the U-label
"аnvilwalrusden" is not all in one script).  This is a policy that Verisign has.

There is, however, nothing at all in Verisign's policy to prevent me
from creating аndrews-laptop.anvilwalrusden.com
(xn--ndrews-laptop-v1k.anvilwalrusden.com).  And there's nothing in
the protocol to prevent it.  If you want to say, "Mixed script labels
are not allowed anywhere in the DNS," I think you're going to have
some push-back.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]