From mailnull@www1.ietf.org Wed May 7 00:00:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19698 for ; Wed, 7 May 2003 00:00:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4749Il27553 for discuss-archive@odin.ietf.org; Wed, 7 May 2003 00:09:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4749I827550 for ; Wed, 7 May 2003 00:09:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19675 for ; Wed, 7 May 2003 00:00:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DG85-0004tc-00 for discuss-web-archive@ietf.org; Wed, 07 May 2003 00:02:05 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DG84-0004tY-00 for discuss-web-archive@ietf.org; Wed, 07 May 2003 00:02:04 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4747R827323; Wed, 7 May 2003 00:07:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4746G826560 for ; Wed, 7 May 2003 00:06:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19586 for ; Tue, 6 May 2003 23:56:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DG59-0004sX-00 for discuss@apps.ietf.org; Tue, 06 May 2003 23:59:03 -0400 Received: from grebe.mail.pas.earthlink.net ([207.217.120.46]) by ietf-mx with esmtp (Exim 4.12) id 19DG58-0004sU-00 for discuss@apps.ietf.org; Tue, 06 May 2003 23:59:02 -0400 Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by grebe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19DG5u-0000ue-00; Tue, 06 May 2003 20:59:50 -0700 Date: Tue, 6 May 2003 23:59:38 -0400 From: Keith Moore To: discuss@apps.ietf.org Cc: moore@cs.utk.edu, iesg@ietf.org Subject: LLMNR considreed harmful Message-Id: <20030506235938.2c551071.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: discuss-admin@ietf.org Errors-To: discuss-admin@ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: general discussion of application-layer protocols List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, it's happening again. the dnsext working group is in revision 18 of a draft that drastically and incompatibly changes the DNS API, out from under every application that uses DNS. they've made all kinds of efforts to avoid having LLMNR pollute DNS caches, but done nothing to avoid polluting applications that use DNS and make similar assumptions about DNS integrity. in fact the document explicitly suggests overloading the existing APIs so that lookups intended for DNS will under some conditions instead be redirected to LLMNR - even though LLMNR is supposed to look up a completely different set of names. (though the examples are all written in terms of FQDNs.) furthermore it is entirely possible that some hosts on a link will have their queries sent to DNS while others will have their queries handled by LLMNR servers, again completely transparently to the applications, producing inconsistent results for identical queries. the amazing thing is that they're in revision 18 and still have these fundamental flaws. From mailnull@www1.ietf.org Wed May 7 15:29:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14488 for ; Wed, 7 May 2003 15:29:46 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47JcrH16138 for discuss-archive@odin.ietf.org; Wed, 7 May 2003 15:38:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47Jcr816135 for ; Wed, 7 May 2003 15:38:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14449 for ; Wed, 7 May 2003 15:29:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DUdM-00042c-00 for discuss-web-archive@ietf.org; Wed, 07 May 2003 15:31:20 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DUdL-00042Z-00 for discuss-web-archive@ietf.org; Wed, 07 May 2003 15:31:19 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47Jb4815298; Wed, 7 May 2003 15:37:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47GuP801314 for ; Wed, 7 May 2003 12:56:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07887 for ; Wed, 7 May 2003 12:46:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DS6B-0002qV-00 for discuss@apps.ietf.org; Wed, 07 May 2003 12:48:55 -0400 Received: from tux.w3.org ([18.29.0.27]) by ietf-mx with esmtp (Exim 4.12) id 19DS6B-0002qS-00 for discuss@apps.ietf.org; Wed, 07 May 2003 12:48:55 -0400 Received: from enoshima (tux.w3.org [18.29.0.27]) by tux.w3.org (8.12.9/8.12.9) with ESMTP id h47Gndc1014827; Wed, 7 May 2003 12:49:46 -0400 Message-Id: <4.2.0.58.J.20030507114917.041632c0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Wed, 07 May 2003 11:50:12 -0400 To: Keith Moore , discuss@apps.ietf.org From: Martin Duerst Subject: Re: LLMNR considreed harmful Cc: iesg@ietf.org In-Reply-To: <20030506235938.2c551071.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: discuss-admin@ietf.org Errors-To: discuss-admin@ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: general discussion of application-layer protocols List-Post: List-Help: List-Subscribe: , Hello Keith, This seems to be a serious problem. Could you give some more information, at least some pointers to the relevant drafts and an expansion of LLMNR? Regards, Martin. At 23:59 03/05/06 -0400, Keith Moore wrote: >Folks, > >it's happening again. > >the dnsext working group is in revision 18 of a draft that drastically and >incompatibly changes the DNS API, out from under every application that uses >DNS. they've made all kinds of efforts to avoid having LLMNR pollute DNS >caches, but done nothing to avoid polluting applications that use DNS and make >similar assumptions about DNS integrity. in fact the document explicitly >suggests overloading the existing APIs so that lookups intended for DNS will >under some conditions instead be redirected to LLMNR - even though LLMNR is >supposed to look up a completely different set of names. (though the >examples are all written in terms of FQDNs.) > >furthermore it is entirely possible that some hosts on a link will have their >queries sent to DNS while others will have their queries handled by LLMNR >servers, again completely transparently to the applications, producing >inconsistent results for identical queries. > >the amazing thing is that they're in revision 18 and still have these >fundamental flaws. From mailnull@www1.ietf.org Wed May 7 17:05:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17574 for ; Wed, 7 May 2003 17:05:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47LEjL24317 for discuss-archive@odin.ietf.org; Wed, 7 May 2003 17:14:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47LEj824314 for ; Wed, 7 May 2003 17:14:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17562 for ; Wed, 7 May 2003 17:05:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DW86-0004lb-00 for discuss-web-archive@ietf.org; Wed, 07 May 2003 17:07:10 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DW86-0004lY-00 for discuss-web-archive@ietf.org; Wed, 07 May 2003 17:07:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47LD0824193; Wed, 7 May 2003 17:13:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47L3t822664 for ; Wed, 7 May 2003 17:03:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17206 for ; Wed, 7 May 2003 16:54:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DVxc-0004fo-00 for discuss@apps.ietf.org; Wed, 07 May 2003 16:56:20 -0400 Received: from astro.cs.utk.edu ([160.36.58.43]) by ietf-mx with esmtp (Exim 4.12) id 19DVxb-0004fl-00 for discuss@apps.ietf.org; Wed, 07 May 2003 16:56:19 -0400 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h47Kv9v13433; Wed, 7 May 2003 16:57:10 -0400 (EDT) Date: Wed, 7 May 2003 16:57:09 -0400 From: Keith Moore To: Martin Duerst Cc: moore@cs.utk.edu, discuss@apps.ietf.org Subject: Re: LLMNR considreed harmful Message-Id: <20030507165709.6d8320ac.moore@cs.utk.edu> In-Reply-To: <4.2.0.58.J.20030507114917.041632c0@localhost> References: <20030506235938.2c551071.moore@cs.utk.edu> <4.2.0.58.J.20030507114917.041632c0@localhost> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: discuss-admin@ietf.org Errors-To: discuss-admin@ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: general discussion of application-layer protocols List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > This seems to be a serious problem. Could you give some > more information, at least some pointers to the relevant > drafts and an expansion of LLMNR? the draft is draft-ietf-dnsext-mdns-18.txt LLMNR = Linklocal Multicast Name Resolution problems in slightly more detail: 1. The goals and usage scope for the protocol are unclear. It seems to be targeted at isolated, nomadic, or intermittently connected newtorks which need to support some form of name lookup but don't have reliable DNS service. Also the idea is to clearly to provide the name lookup without requiring a central server, an approach which would be useful in ad hoc or unmanaged networks. The first paragraph of the Introduction says that LLMNR "cannot be considered a substitute for DNS". And yet the next sentence states that a goal is to support name lookup on hosts that aren't configured with the address of a DNS server - presumably even though one might be available. Similarly section 3 states that "LLMNR...is not intended as a replacement for DNS" and then immediately suggests that LLMNR requests should be sent under a variety of conditions when DNS is not available, or when DNS does not respond. In other words, the disclaimers notwithstanding, LLMNR clearly is substituting for or replacing DNS under some set of ill-defined conditions which vary from one host to another. The abstract implies that it targets home networks, but home networks that are connected to the Internet do have DNS service. 2. It's clear that the LLMNR protocol is based on DNS, but the intended relationship between LLMNR and DNS is not clear. - It appears to be assumed that the same server might respond to both DNS queries and LLMNR queries (section 2.2) - LLMNR claims to support all record types of DNS, but it doesn't require the use of NS records to delegate lookups. - All of the examples use fully-qualified DNS-style names, implying that ordinary DNS names are used in LLMNR, and yet section 3 says that LLMNR queries SHOULD be only for names which are either unqualified or "in the default domain". (never mind that domain names have nothing to do with network topology... we're assuming that it's okay for the local network to answer queries for a host's default domain even when the host's domain may have nothing to do with the link.) - section 2.2. says "Responders MUST NOT respond to LLMNR queries for names that they're not authoritative for", thus implying some notion of authority, but this authority is not defined. - there is no advice on consistency between LLMNR and DNS. for instance there's no stated responsibility for a host to keep LLMNR and DNS consistent under any set of conditions, and in fact LLMNR servers are expected to use constant TTLs (where these might differ from those in DNS) and omit RRs from responses that might be provided in DNS. 3. LLMNR changes semantics of DNS lookup, and overloads semantics of existing APIs apparently it is intended that existing APIs for DNS lookup will be overloaded to use LLMNR under some conditions which would otherwise produce DNS lookup errors. applications that expect the existing behavior may break, and they are also subject to additional attacks. finally the additional time needed to attempt LLMNR queries will result in additional delays for the application. LLMNR will produce results that are inconsistent with DNS, and there's no way for an application to specify what kind of query to use or to tell that it's getting LLMNR instead of DNS. LLMNR has the potential for multiple answers from multiple sources to the same query, DNS does not normally exhibit this (though a DNS implementation could follow multiple NS paths and perhaps get varying results to the same query from multiple NSes, it should find that the serial numbers differ, and thus be able to resolve the conflict.)