Subject: Re: DNSEXT Document Review: LLMNR-45

From: "Dave Thaler" <[email-masked]>
Date: Mon, 6 Feb 2006 13:54:32 -0800

I agree that issue #1 is out of scope for the LLMNR spec.

On issue 2:
> (2) Security concerns have been raised about the fact that
> applications on hosts that implement LLMNR will not be able to tell
> if a response has come from the DNS or from a local lookup.

Tony Finch wrote:
> What changes should be made to RFC 3493 as a consequence of LLMNR?

Stephane Bortzmeyer wrote:
> I regard issue 2, above, as a non-issue: other name resolution
> Techniques like /etc/hosts or LDAP have the same behavior and nobody
> complained that getnameinfo() cannot tell you from which service you
> got the IP address.
> 
> May be just a small addition in Security Considerations:
> 
> Implementations should [lowercase, not RFC 2119] allow the system
> administrator to disable completely the use of LLMNR [like what you
> can do with a typical /etc/host.conf or equivalent].

Eric Hall wrote:
> This is a feature not a bug. [That is, if multiple ~standardized
naming
> services are going to be ~supported, then application interoperability
> between them would be a feature. I mean, NIS and NetBIOS names (and
> /etc/hosts too) can be used by applications without needing to
understand
> the actual resolution service and providing similar functionality here
> would be a competitive feature.]

Re issue #2, I agree with Stephane and Eric.  There is nothing in RFC
3493
which needs to change as a result of LLMNR specifically.  The same
security
concerns are independent of the protocol.  If anything in RFC 3493 were
to
change in the future, I would suggest that the addrinfo structs returned
be
able to include information about any important characteristics of the 
results, and those characteristics be protocol independent.  For
example,
"whether it was obtained securely or not" might be interesting, which in

DNS might mean whether they were DNSSec protected, or whatever.  This
would
be a much better way to address the concerns, and it is out of scope for
LLMNR in my view, but in scope for the WG (under the debatable
assumption 
that APIs are in scope in the IETF in the first place).

On issue #3, I am fine with draft -45 for the same reasons as above.

-Dave

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 09 Feb 2006 00:48:30 -0500

I've been thinking about the security and naming scope problems a little
bit and have reached the conclusion that we need to do something here.

On 2/6/2006 4:54 PM, Dave Thaler wrote:

> Re issue #2, I agree with Stephane and Eric.  There is nothing in RFC 3493
> which needs to change as a result of LLMNR specifically.  The same security
> concerns are independent of the protocol.

This is true but it also ignores the fact that we are responsible for
*this* protocol. Being broken elsewhere doesn't mean we should design for
broken here too, and if anything we are kind of incumbent to put our money
where our mouths are.

I think there's an easy hack here that gets us about 80% through the
problem space--just limit the namespace to single-label names, so that
there's no overlap with the DNS namespace.

On the security side, do we really need handhelds claiming to be
www.paypal.com? On the namespace side, forbidding such claims prevents
collisions with the authoritative space.

This leaves the security hole of single-label names resolving to forged
nodes (a handheld claims to be an HR server), and we're all undoubtedly
aware that any risk is a 100% risk once it's widely exploited, but these
kind of relative-name attacks can also be dealt with at application layers
(certs, etc).

This also leaves some opportunity for vendors to put their own .local
interoperability hacks together without our blessing or permission.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>