Re: [dnssd] Multicast DNS (mDNS) Threat Model and Security Consideration
"Hosnieh Rafiee" <ietf@rozanak.com> Thu, 16 April 2015 20:46 UTC
Return-Path: <ietf@rozanak.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65551B36BD for <dnssd@ietfa.amsl.com>; Thu, 16 Apr 2015 13:46:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.79
X-Spam-Level:
X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 ZRBNv4SXZYAz for <dnssd@ietfa.amsl.com>; Thu, 16 Apr 2015 13:46:02 -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 4ADC31B36A0 for <dnssd@ietf.org>; Thu, 16 Apr 2015 13:46:02 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id A3B5425CA274; Thu, 16 Apr 2015 20:45:59 +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 d4SaBiLMrQZU; Thu, 16 Apr 2015 22:45:57 +0200 (CEST)
Received: from kopoli (p5DCC6085.dip0.t-ipconnect.de [93.204.96.133]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 2AEA725CA22A; Thu, 16 Apr 2015 22:45:57 +0200 (CEST)
From: Hosnieh Rafiee <ietf@rozanak.com>
To: "'Albrecht, Harald'" <harald.albrecht@siemens.com>
References: <E36F274013087B4EA05E08EB503750390BF63956@DEFTHW99EK5MSX.ww902.siemens.net>
In-Reply-To: <E36F274013087B4EA05E08EB503750390BF63956@DEFTHW99EK5MSX.ww902.siemens.net>
Date: Thu, 16 Apr 2015 22:45:51 +0200
Message-ID: <002a01d07886$54cf31c0$fe6d9540$@rozanak.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQH88HqhcGrpppT3rde6MaTcSsoJApz3G1bQ
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnssd/GAF1thhJ3w9m8lTCMuyVXPxQxbY>
Cc: dnssd@ietf.org
Subject: Re: [dnssd] Multicast DNS (mDNS) Threat Model and Security Consideration
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: Thu, 16 Apr 2015 20:46:05 -0000
Hi Harald, Thanks a lot for your comments and deep review. I will apply them in next version. > > Hi, > > just came across a few minor things in the DNSSD I-D "Multicast DNS (mDNS) > Threat Model and Security Consideration" -02. > > In section 3.2.2, second scenario the term "Time To Leave" for TTL should be > "Time To Live" instead > (http://en.wikipedia.org/wiki/Domain_Name_System#DNS_resource_records > <http://en.wikipedia.org/wiki/Domain_Name_System#DNS_resource_records > > ). Albeit I have to admit that "time to leave" has a very nice ring :) OMG... it made me smile too... what a funny mistake I did.. :-) . > > In section 3.3.1 you write "[.] these services may automatically announce > over mDNS both Universal Local Addresses (ULA) [RFC4193] and Global > Unicast Addresses (GUA). Since a GUA address is global, the associated node > may become accessible over the Internet." I think that the second GUA > reference should be to ULAs instead, that is, "Since a ULA address is global > [.]". True if the router is not configured to not route ULAs by default. I guess I have a lot of nits in this version... Unique Local addresses... (you're right universal and global are the same..) > Another thing that strikes me is the use of "GUA address" and "ULA address". > The "A" in "GUA" and "ULA" already means address, so "GUA address" > basically means a "global unicast address address". Either a sole "GUA"/"ULA" > is already sufficient or always spell "global unicast address" in full. True! > With respect to section 3.7.1 "Storing mDNS names in unicast DNS" I wonder if > there are attacks possible based on leaking UTF-8 labels into unicast DNS and > thus upsetting either DNS servers, (stub) resolvers, and IDNA libraries? I think it is possible to fool a human with different similar characters (possible phishing) in case a DNS server also accepts non-ASCII chars. But not sure this can make any problem for a DNS server itself when the DNS implementation checks the exact matching of a query name. So, this really depends on the implementation of a DNS server. > In section 3.13.4.1 what is the security standpoint rationale to not publish > GUAs? For instance, if a site decides to not use ULAs but only GUAs (believe > me, there are such huge sites in IPv4 that run their company intranet on > global addresses, not on private ones) then this would not be less secure than > using ULAs. Some moments before the draft argues with respect to ULA > accessibility. The same also applies to GUAs. Not publishing something doesn't > mean it's not reachable - this would be a perfect example of security by > obscurity. And security by obscurity is known to not offer any security at all. > So, please detail the rationale behind 3.13.4.1 and it focusing on ULA only. > Maybe for a website, it is less critical to separate the local and global. However, many companies make their high critical resources only available internally to make the risk lower. I think for services (like printer, fax, etc.) in the network it is critical to consider a clear scope. The scope can be also global but might be limited to only a certain range of external IP addresses. This is, of course, what might not be possible to define in the service itself, but in the security devices of a network that offers this service (like a firewall, or even a router to only route certain range of external IP to a service or not route the service responses to certain range of IP addresses), this is possible. This is because there might be high risk, if the range of IPv6 addresses is already known or there is available method to know which IPv6 address is in use in a target network. This gives an attacker a possibility to gain access to , e.g., a fax machine and sends his own faxes with the cost of others! . Although the fax machine is considered to have an access list but usually such devices have a low memory and very light OS that might support weak security. Unfortunately, such devices also might support a web user interface that even might not support SSL protocol... so attractive for an attacker! When the IP address is local and it is not routed outside of its local range, then the risk of attacks on a service is lower. Because an attacker needs to be in the exact local network of this service so that it can abuse this service. this is more difficult than when considering the case that an attacker is located in his own home or a coffeenet close to his home and tries to find a free fax machine on a internet. So what I would like to highlight here is that the definition of scope is really important. When the scope is smaller the chance of attack is lower. When ULA are not routable then the attack is limited to only local nodes, when the service uses GUAs then the chance of attack is higher because it might allow all over the internet to attack a service in a network. I hope I could answer your questions. Thanks again, Best, Hosnieh
- [dnssd] Multicast DNS (mDNS) Threat Model and Sec… Albrecht, Harald
- Re: [dnssd] Multicast DNS (mDNS) Threat Model and… Hosnieh Rafiee
- Re: [dnssd] Multicast DNS (mDNS) Threat Model and… Douglas Otis