Re: [dnssd] Any review of Threat model?

[Andrew Sullivan <[e-mail]>]

Hi,

On Mon, Apr 04, 2016 at 09:47:31PM +0200, Hosnieh Rafiee wrote:
> >Different issues all seem to be treated as "threats" without any way
> >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.

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
[e-mail]