Bernard Aboba <[EMAIL PROTECTED]> writes: > 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.
We agree that home burglary is a serious problem. This is why we recommend that everyone hire an armed guard for their house. If your house is monitored by armed guards, burglary is very unlikely. Given that there is an effective security mechanism available, there's really no need to consider simple deterrants that won't provide true security. > c. Lack of consideration of existing practice. Internet hosts have used > multiple name resolution mechanisms based on a single API for more than > two decades, with no ill effects. "No ill effects" is a horribly inaccurate description of the effects of that design. A much more accurate description would be that Internet hosts have used multiple name resolution mechanisms through a single API out of necessity for more than two decades, have suffered frequent ill effects up to and including major outages because of it, but have struggled along with that design because there are some features provided by it that are too useful to completely dismiss in general. That being said, most systems attempt to avoid using those features when feasible and attempt to make all sources of information match exactly to avoid the serious and often hard-to-diagnose problems of conflicting information. If you think that using /etc/hosts, NIS, and DNS at the same time on systems to provide name resolution is a *success* story, your perceptions of the practical problems of name resolution in Internet hosts is drastically different than mine. You've also had to maintain far less code to try to work around bizarre inconsistencies in gethostbyname responses than I have. > I must admit that at one point, I did not see value in funding the RFC > Editor to publish documents outside of the IETF process, via the RFC > Editor Individual Submission route, described in RFC 3932. However, now > it has become abundantly evident that this represents an important > safety mechanism that needs to be preserved going forward. I suppose that's one reaction to a general IETF mailing list consensus that a protocol raises serious concerns. I don't think it's a particularly useful one, though. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
