Re: [dnssd] Any review of Threat model?

[Tim Chown <[e-mail]>]

Hi,

We have some time at the end of the session in Berlin to discuss the future of the DNSSD Threats draft, as per https://tools.ietf.org/html/draft-otis-dnssd-scalable-dns-sd-threats-03

At present, there are outstanding unresolved comments at least from Andrew Sullivan, from the thread below, and as archived in the mail list archive at https://mailarchive.ietf.org/arch/search/?email_list=dnssd&gbt=1&index=H-BRUJFcg_aBLMtA3l3Pfh8CYns.

Doug is currently not available to work on the document, so if it is to be progressed Hosnieh will be looking for additional volunteers.

Comments in advance of the meeting are welcome.

Tim 



> On 4 Apr 2016, at 22:58, Andrew Sullivan <[e-mail]> wrote:
> 
> Hi,
> 
> On Mon, Apr 04, 2016 at 10:44:16PM +0200, Hosnieh Rafiee wrote:
> 
>> 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.
> 
> 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
> [e-mail]
> 
> _______________________________________________
> dnssd mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnssd