From nobody Sat Sep 3 11:31:11 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4DD12B0A8 for ; Sat, 3 Sep 2016 11:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.507 X-Spam-Level: X-Spam-Status: No, score=-1.507 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.508] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omViACoohWaE for ; Sat, 3 Sep 2016 11:31:05 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35922128E18 for ; Sat, 3 Sep 2016 11:31:05 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id B045C25CA27E for ; Sat, 3 Sep 2016 18:31:02 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFIGHuItdyEF for ; Sat, 3 Sep 2016 20:30:32 +0200 (CEST) Received: from p200300864F147D99A288B4FFFE18E5F0.dip0.t-ipconnect.de (p200300864F147D99F2DEF1FFFE58C5D4.dip0.t-ipconnect.de [IPv6:2003:86:4f14:7d99:f2de:f1ff:fe58:c5d4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 984B725CA242 for ; Sat, 3 Sep 2016 20:30:32 +0200 (CEST) To: dnssd@ietf.org References: <56FFE286.9010304@rozanak.com> <20160404191306.GA36990@anvilwalrusden.com> <5702C4D3.5070500@rozanak.com> <20160404200942.GE36990@mx2.yitter.info> <5702D220.2000501@rozanak.com> <20160404215837.GE37449@mx2.yitter.info> From: Hosnieh Rafiee Message-ID: <59eff740-de2c-65b1-26ab-06dba5cc2b09@rozanak.com> Date: Sat, 3 Sep 2016 20:30:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F6EF2B2FC51783E2CF280B63" Archived-At: Subject: Re: [dnssd] Any review of Threat model? X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2016 18:31:07 -0000 This is a multi-part message in MIME format. --------------F6EF2B2FC51783E2CF280B63 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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 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 >> ajs@anvilwalrusden.com >> >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --------------F6EF2B2FC51783E2CF280B63 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

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 <ajs@anvilwalrusden.com> 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
ajs@anvilwalrusden.com

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

--------------F6EF2B2FC51783E2CF280B63-- From nobody Wed Sep 28 10:19:32 2016 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 116D612B27F; Wed, 28 Sep 2016 10:19:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147508317106.16615.2091186492777401347.idtracker@ietfa.amsl.com> Date: Wed, 28 Sep 2016 10:19:31 -0700 Archived-At: Cc: dnssd@ietf.org Subject: [dnssd] I-D Action: draft-huitema-dnssd-privacy-02.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2016 17:19:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery of the IETF. Title : Privacy Extensions for DNS-SD Authors : Christian Huitema Daniel Kaiser Filename : draft-huitema-dnssd-privacy-02.txt Pages : 20 Date : 2016-09-28 Abstract: DNS-SD allows discovery of services published in DNS or MDNS. The publication normally discloses information about the device publishing the services. There are use cases where devices want to communicate without disclosing their identity, for example two mobile devices visiting the same hotspot. We propose to solve this problem by a two-stage approach. In the first stage, hosts discover Private Discovery Service Instances via DNS-SD using special formats to protect their privacy. These service instances correspond to Private Discovery Servers running on peers. In the second stage, hosts directly query these Private Discovery Servers via DNS-SD over TLS. A pairwise shared secret necessary to establish these connections is only known to hosts authorized by a pairing system. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-huitema-dnssd-privacy/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-huitema-dnssd-privacy-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-huitema-dnssd-privacy-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/