Subject: Re: DNSEXT Document Review: LLMNR-45

From: Bernard Aboba <[email-masked]>
Date: Wed, 8 Feb 2006 22:32:34 -0800 (PST)

Eric Hall said:

"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."

If there is no security in place, in most cases it makes sense to only 
send LLMNR queries only for single-label names.  So not much would be lost 
if this were to be required. 

"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."

If the query sender has no ability to validate the claim,  then I would 
agree that an FQDN query should not be sent. 

But what if the sender is DNSSEC validating, and the responder also 
supports DNSSEC, and appropriate trust anchors are in place? Then it 
would be possible for the sender to determine whether the claim was valid 
or not.

"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)."

Actually that is more true of the FQDN spoofing case than it is of the 
single-label case.  After all, you aren't going to see Verisign 
distributing certs with an AltSubjectName of "foo" any time soon. 

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

Since the .local issue was about the behavior of existing resolvers, I 
think that fixing it would require some documentation. 

--
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/>

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 09 Feb 2006 10:13:06 -0500

> distributing certs with an AltSubjectName of "foo" any time soon. 

Couple of other factors here though. For one, the real "HR" host would
have a delegated cert for something like "hr.intranet.example.com". So
even if the key is compromised the name won't match.

It's also possible for local nets to publish LLMNR names for important
systems on the local level. That further reduces the scope of the vector
to (a) being outside the premises, and (b) mimicing the correct name, (c)
redirecting to insecured application [http instead of https], and (d)
faking the application to being the right fake site enough to pull off the
phish (where "hr" has to look like the "hr" that the user is trying to
connect to, which is pretty unlikely if the attack space is off-site
public areas).

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

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 09 Feb 2006 11:41:55 -0500

> systems on the local level. That further reduces the scope of the vector

Another attack vector would of course be denial-of-service, such that the
attacker did not need to redirect the victim but just to block them. This
could work with TLD names like "com" or the like (keep any names within
that space from resolving). Simple fix here is to make it JUST ONE label
(really, just one), so that lookup for "com" would really be a lookup for
"com" instead of "com.<root>". That would limit the attack scope to the
root domain itself (ie, spoofing the zero-length label), which is a
single-instance attack that can be handled with an explicit prohibition in
the spec ("do not generate/process zero-length labels").

Similarly, maybe a prohibition against the dot character (0x2E) or each of
the IDN equivalents would also be useful to prevent some kinds of
look-alike attacks from occurring.