Re: [ietf] DNS spoofing at captive portals

[Keith Moore <[e-mail]>]

On Sep 24, 2010, at 8:38 AM, Alfred HÎnes wrote:

> At Fri, 24 Sep 2010 07:21:21 -0400,  Michael Richardson wrote:
> 
>> Has the IETF (or rather then IAB) written any simple documents that
>> explain to less informed (i.e. marketing/product) managers why it
>> is a bad thing for a captive portal to spoof DNS replies?
>> (not just in regard to DNSSEC, but also in regards to just caching)
> 
> a) Most of the arguments explained in the 2003 IAB Commentary:
>   "Architectural Concerns on the use of DNS Wildcards",
>   <http://www.IAB.ORG/documents/docs/2003-09-20-dns-wildcards.html>,
>   apply in a similar fashion, but it indeed would be a good idea
>   to produce such document.  I think much text from 2003 could
>   be leveraged.

One important thing to realize is that this kind of "service" isn't always implemented using wildcards.  Sometimes the "service" is implemented using interception proxies.

> b) It should be clearly spelled out that this practice falls among the
>   category of actions commonly known as man-in-the-middle attacks.

Agreed.  Actually, when a server or interception proxy deliberately misrepresents the contents of others' DNS zones, the appropriate term (IMO) is "fraud".   

IANAL but would think that such practice should expose the operator of the server or proxy to civil and/or criminal action, both from the operators of the zones whose RRs are being misrepresented, and from the users' whose applications are affected.

> c) draft-livingood-dns-redirect and draft-livingood-dns-malwareprotect
>   descibe these "services" in a much too friendly tone;

Strongly agree, at least for the -redirect draft.  At the very least, a distinction needs to be made between services which the individual user deliberately chooses, and services which are imposed without the users' knowledge or consent.  The draft also glosses over the problems created by this practice for all applications other than web browsing by human beings.   Not only does this provide misleading error indications for all other applications, it even breaks applications that are layered on top of HTTP.

> d) In my personal opinion, the original idea of having recursive
>   DNS resolvers located "close to the hosts" should be given more
>   traction again in the future.  All kinds of SOHO access gateways
>   or home gateways should preferably offer (locally) full recursive
>   and validating DNS resolution service.

Agree with this also.  In many cases the ideal model seems to be one in which the host serves as its own primary DNS server, or at least as the master DNS zone. 

Keith