[dnssd] Threat model - answer to questions

Hosnieh Rafiee <hosnieh.rafiee@huawei.com> Fri, 14 November 2014 15:08 UTC

Return-Path: <hosnieh.rafiee@huawei.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id AF24A1A1A6D for <dnssd@ietfa.amsl.com>; Fri, 14 Nov 2014 07:08:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.795
X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id MLGk9etTqIXR for <dnssd@ietfa.amsl.com>; Fri, 14 Nov 2014 07:08:53 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E30271A19F5 for <dnssd@ietf.org>; Fri, 14 Nov 2014 07:08:52 -0800 (PST)
Received: from (EHLO lhreml405-hub.china.huawei.com) ([]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOU30026; Fri, 14 Nov 2014 15:08:51 +0000 (GMT)
Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml405-hub.china.huawei.com ([]) with mapi id 14.03.0158.001; Fri, 14 Nov 2014 15:08:47 +0000
From: Hosnieh Rafiee <hosnieh.rafiee@huawei.com>
To: "dnssd@ietf.org" <dnssd@ietf.org>
Thread-Topic: Threat model - answer to questions
Thread-Index: AdAAHOI1IabjPMLgS8G9/moucSe3Jg==
Date: Fri, 14 Nov 2014 15:08:46 +0000
Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A5E576@lhreml513-mbb.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/b56f42hPXSaDrLXfhT_z6xnWJ6A
Subject: [dnssd] Threat model - answer to questions
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Nov 2014 15:08:59 -0000


Thanks folks for taking your time to listen to my presentation. I do not know how was the quality. Since on my side I didn't see any face to react based on the faces of people. Probably if I was onsite and I could see the faces with big question mark during presenting the tables, I could clarify everything. 

I would like to answer some of unanswered questions/comments that raised during my presentation and any aspects that confused folks. 
(The names might not be accurate as I might confused the discussion of one person with another) 

1- There was discussion about privacy in local links (I think raised by Dave)

Answer: I agree that privacy in general is really important. What I wanted to point out during my presentation by my (confusing table) was that for DNS-SD when the scope is only local link ,privacy might not be a big issue because
 - service provider (a printer) needs to publicly advertise its service inside the local link. Nothing can be hide without this multicast or broadcast messages
In other word, service provider cannot hide any information 

 - MAC addresses are also known to other nodes and hiding any IP address or names of service providers does not much help to increase privacy in local link. But this might be a big issue if the scope is larger and we are talking the privacy inside enterprise network consisting on several local link.

2- DNSSD uses both unicast DNS and multicast DNS (I think raised by Cheshire) 

Answer: This is true. In first slide I explained the differences of unicast DNS with DNS-SD. Therefore I only talked about sending multicast messages
In second slide I discussed about the similarities of these two. Therefore, I only talked about both sending unicast messages. This was also as a part of slides' title. If I passed on it very quickly then someone should ask me to slow down as I received no feedback during presentation :-| and could not see your faces to know when I should explain something more or when I should just skip a slide.

3- Why we need to compare unicast DNS with DNSSD? (I think raised by Cheshire)

Answer: The comparison is just because to find out the threat scope. As folks already know, there are lists of known threats that is applicable to unicast DNS. When there is any similarities between the FUNCTIONS of two protocols, all of these threats can be applicable to DNSSD the same way as it is applicable to unicast DNS. Then there is possibility to check the current available mechanisms and check to see whether with current requirements that exist in DNSSD, whether or not we need another security mechanism or whether or not we need to any extension to current available security mechanism or whether or not we can use them as it is.  

4- Not agree that DNSSEC cannot be in solution space (Dave)

Answer: I just explained in the draft it cannot be a solution space when we are talking about zero configuration or plug and play solutions or minimal configuration. If you are also talking about DANE + DNSSEC, the list of trusted anchors need to be introduced to your clients and also service advertiser (that I called it service provider).  IMO this is not minimum configuration. Since it is a requirement for each single nodes. This is almost not feasible for public wireless networks. There might be different ways to propagate this trusted lists to all nodes but probably there are other requirements such as all nodes are inside one ADs domains or subdomains. 
But configuration of middle boxes, routers and switches, IMO, is considered minimal configuration since it is only limited to certain number of devices. It is also possible to simplify this if the network supports software defined networking (SDN) based approaches as I explained in my last slide but as a new use case for SSD. However It can be also a helpful solution for minimum configuration. 

Any thought?

5- overlay networks and SSD (Douglas)

Answer: I still do not understand what is the relationship of overlay networks to SSD. This was the case I did not know what to answer to your question. Why should we consider this? What will happen if we do not consider this?

6- what is the relationship between spoofing and privacy (Dave)

Answer: the rows in the table did not have any relationship to eachother. I just used the rows to separate two different threats in one column but it was nothing to do with the relationship of, e.g., group  of threats in column 1 row 1 to column 3 row 1. I guess I had to remove the lines between rows so that people did not have this misinterpretation of my tables. I only had 3 groups (each in one columns) that the first group of threats was shared between both, e.g., SSD and DNS-SD. One was only specific to DNS-SD and the last one was specific to SSD. This is also true for other table, i.e, unicast DNS vs DNS-SD.

Please share your thoughts.