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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf