Re: Summary of the LLMNR Last Call
Margaret Wasserman <margaret@thingmagic.com> Tue, 20 September 2005 09:17 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHeFs-0005UB-64; Tue, 20 Sep 2005 05:17:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHeFp-0005Qw-BW for ietf@megatron.ietf.org; Tue, 20 Sep 2005 05:17:33 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17809 for <ietf@ietf.org>; Tue, 20 Sep 2005 05:17:30 -0400 (EDT)
Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHeLc-0006jk-TB for ietf@ietf.org; Tue, 20 Sep 2005 05:23:33 -0400
Received: from [66.30.121.250] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 524596; Tue, 20 Sep 2005 05:19:05 -0400
Mime-Version: 1.0
Message-Id: <p06200755bf557e9290de@[192.168.2.2]>
In-Reply-To: <Pine.LNX.4.61.0509192043550.28535@internaut.com>
References: <Pine.LNX.4.61.0509191647510.23762@internaut.com> <p0620074fbf5509dd070a@[192.168.2.2]> <Pine.LNX.4.61.0509192043550.28535@internaut.com>
Date: Tue, 20 Sep 2005 05:16:22 -0400
To: Bernard Aboba <aboba@internaut.com>
From: Margaret Wasserman <margaret@thingmagic.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: ietf@ietf.org
Subject: Re: Summary of the LLMNR Last Call
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
Hi Bernard, At 9:31 PM -0700 9/19/05, Bernard Aboba wrote: >a. Confusing DNS resolver behavior with the behavior of LLMNR >implementations. The sending of .local queries to the global DNS, while >potentially a serious problem, results from the behavior of existing DNS >resolver implementations. This problem exists today on the vast >majority of Internet hosts, which do not implement either mDNS or >LLMNR. Given this, putting language into the LLMNR specification >to "fix" an orthogonal issue makes no sense. You might note that in the technical discussion, I argued _against_ the idea that this is a problem with LLMNR. Personally, I consider the fact that mDNS attaches special semantics to .local to be a problem with mDNS. However, reading over the very large number of messages in this thread, it is clear that my arguments were not persuasive enough to change the views of the people who raised this objection, and that the consensus view expressed during IETF LC was that we should not publish LLMNR until this issue is addressed. I made my best attempt in my summary message to fairly represent the view of the community as I saw it expressed in this debate, but I may not have done a great job because it is not a view that I personally hold. >b. Confusion between security issues and namespace separation. In >peer-to-peer name resolution protocols, it is possible for a responder to >demonstrate ownership of a name, via mechanisms such as DNSSEC. It is >also possible for a responder to demonstrate membership in a trusted >group, such as via TSIG or IPsec. If DNSSEC is available, spoofing >attacks are not possible, and querying for FQDNs does not expose the >sender to additional vulnerabilities. Both the mDNS and LLMNR >specifications agree on this point. I read and re-read the LLMNR Security Considerations section hoping to find a mandatory-to-implement security mechanism, so that I could use that fact to counter the points that were raised in IETF LC, and I couldn't find one. If there is any mandatory-to-implement security in LLMNR, could you please point out what it is and where the document indicates that it is required? Absent any mandatory-to-implement security, we sometimes accept an applicability statement that explains the environments in which it is safe to use a protocol without any protocol-specific security mechanism, but I didn't find that in the LLMNR document either. Is it there? Given that I could not find either of these things, it is my technical opinion that LLMNR creates new threats that are not adequately addressed in the document, and these threats need to be addressed before the document is sent to the IESG for review. I realize that these threats already exist in deployed code, but existing practice is not the only criteria that we use for assessing whether a specification is suitable for publication as a Proposed Standard. I missed this issue during my AD Review, for which I apologize. However, I am confident that if the community had not caught this issue, one of the other IESG members would have raised this issue during IESG review. Margaret _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- Summary of the LLMNR Last Call Margaret Wasserman
- Re: Summary of the LLMNR Last Call Stuart Cheshire
- Re: Summary of the LLMNR Last Call grenville armitage
- Re: Summary of the LLMNR Last Call Margaret Wasserman
- Re: Summary of the LLMNR Last Call Bernard Aboba
- Re: Summary of the LLMNR Last Call Margaret Wasserman
- Re: Summary of the LLMNR Last Call Bernard Aboba
- Re: Summary of the LLMNR Last Call Russ Allbery
- Re: Summary of the LLMNR Last Call Bernard Aboba
- Re: Summary of the LLMNR Last Call Russ Allbery
- Re: Summary of the LLMNR Last Call Margaret Wasserman
- Re: Summary of the LLMNR Last Call Margaret Wasserman
- Re: Summary of the LLMNR Last Call Bernard Aboba
- Re: Summary of the LLMNR Last Call Steven M. Bellovin
- Re: Summary of the LLMNR Last Call Bernard Aboba
- Re: Summary of the LLMNR Last Call Ned Freed
- Re: Summary of the LLMNR Last Call Robert Elz
- Re: Summary of the LLMNR Last Call Margaret Wasserman
- .local [Re: Summary of the LLMNR Last Call] Brian E Carpenter
- Re: .local Frank Ellermann
- Re: Summary of the LLMNR Last Call Bill Manning
- 2606bis (was: .local) Frank Ellermann
- Re: 2606bis (was: .local) John C Klensin
- Re: 2606bis (was: .local) JFC (Jefsey) Morfin
- Re: 2606bis Frank Ellermann
- Re: 2606bis Bill Fenner
- Re: 2606bis John C Klensin
- Re: 2606bis JFC (Jefsey) Morfin
- Re: 2606bis Brian E Carpenter