Re: [dnssd] Any review of Threat model?

[Hosnieh Rafiee <[e-mail]>]

All,

Is there anybody who likes to contribute to this draft and help to
fininlize it and address the final comments?

Thanks,

Best,

Hosnieh


On 07/12/2016 01:07 PM, Tim Chown wrote:
> 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
> _______________________________________________
> dnssd mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnssd