Subject: [AAA-DOCTORS] Secdir review of draft-ietf-dnsext-dnsproxy-05

From: Alan DeKok <[email-masked]>
Date: Sat, 30 May 2009 09:31:08 +0200

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

  Over all, the document appears to be clear.

  I wonder about the following text in section 4.5, however:

   NB: any DNS proxy (such as those commonly found in WiFi hotspot
   "walled gardens") which transparently intercepts all DNS queries, and
   which returns unsigned responses to signed queries, will also cause
   TSIG authentication failures.

  The problem with WiFi hotspot DNS proxies is much, much, worse than
this simple paragraph would suggest.  There are issues found in in those
deployments that are not discussed in this document.  I will summarize
them here:

Issue: responding to all DNS requests with the IP of the hotspot

Goal: to guide all client traffic to the hotspot

Background: Many client machines have VPN software that checks for the
existence of "internal" corporate DNS names.  If the names resolve, the
client is assumed to be "within" the corporate network.  If the name
does not resolve, the client is assumed to be elsewhere, and the VPN
software behaves differently.  DNS proxies that return an answer for all
names result in the client erroneously believing it is in the "internal"
network.  Various things then fail in weird and wonderful ways.

  Even when VPN software doesn't exist, this practice can cause other
problems.  A commonly used web browser (I.E. from a major vendor) can
cache the results of DNS queries at the application layer.  This
information is cached even across DHCP lease assignments from a new
subnet, where DNS caches are usually flushed.  The result is that the
web browser cannot view the first web page that the user tries to visit.
The captive portal page is always shown instead.

Suggestion: DNS proxies MUST NOT respond with an answer if the name is
not resolvable.  DNS proxies MUST NOT synthesize an answer.

Issue: responding to all DNS requests with a fake IP (commonly 1.1.1.1)

Goal: to catch *different* kinds of traffic than the previous issue
(this is no explanation, I've never had one explained to me in a way I
understand)

Background: Some proxies return synthetic responses with "fake" IP
addresses.  While 1.1.1.1 is not currently allocated, it may be in the
future.  Using it is a bad choice.  In fact, this whole practice is
completely wtong.

Suggestion: Same as above.  DNS proxies MUST NOT synthesize an answer.

  The above suggestions might be a little strong.  There are valid cases
 where a proxy inside of a corporate network might need to synthesize
incorrect answers.  These situations are better described as "internal
corporate policy".  i.e. Notwithstanding the suggestions above, if you
want to break your own network, there are often valid reasons for doing so.

  Alan DeKok.