Subject: Re: DNSEXT Document Review: LLMNR-45

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

On 2/9/2006 1:32 AM, Bernard Aboba wrote:

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

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/

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