Re: Summary of the LLMNR Last Call

Bernard Aboba <aboba@internaut.com> 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 (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf