ietf
[Top] [All Lists]

Re: [ietf] DNS spoofing at captive portals

2010-09-24 10:53:25
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.

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

c) draft-livingood-dns-redirect and draft-livingood-dns-malwareprotect
   descibe these "services" in a much too friendly tone;
   terms like "service" and "benefits for users" are clearly
   abuse of language -- the above IAB statement already indicates
   that similar interference with the DNS causes severe damage
   to user perception and performance.
   These drafts should clearly spell out the downside of these
   methods and their fundamental nature, being MitM attacks.

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.  The ISP-based DNS recursor
   was (and perhaps still is) a good idea in low-bandwidth (dial-in)
   access networks, where the (bandwidth and monetary) costs of full
   DNS service actually matter and are detrimental for the users, but
   it does not make sense any more for broadband access networks with
   (almost) bandwidth-usage independent billing models (flat rates).

   Thus the dependency on (both technically and policy-wise!) powerful
   "central" caching resolvers could be reduced dramatically.
   DNSSEC validation makes most sense for applications when performed
   as close as possible to the stub resolver, if the latter cannot
   perform this function itself; this way, the unprotected path
   at least is constrained to within the users' sites and hence their
   own "administrative domain".
   Experience has shown that huge central resolver systems are very
   attractive targets for external attacks as well as for insider
   attacks (like ${subject}).

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah(_at_)TR-Sys(_dot_)de                    
 |
+------------------------+--------------------------------------------+

-
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf