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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf