This document is probably relevant, although it goes the route of
"providing guidelines for minimum breakage" rather than forbidding.
<http://tools.ietf.org/html/draft-livingood-dns-redirect-02>
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.
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.de |
+------------------------
+--------------------------------------------+
-
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf