Re: [dnssd] Any review of Threat model?

[Andrew Sullivan <[e-mail]>]

Hi,

On Sat, Apr 02, 2016 at 05:17:26PM +0200, Hosnieh Rafiee wrote:
> 
> 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

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