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