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@xxxxxxxxx | +------------------------+--------------------------------------------+ - _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf