Re: [DNSOP] Review of draft-livingood-dns-redirect-00

[Andrew Sullivan <[e-mail]>]

Dear colleagues,

On Thu, Jul 09, 2009 at 11:23:48AM -0400, Livingood, Jason wrote:
> If anyone is interested and has time before IETF 75, I¹m happy to take
> feedback before then obviously.  Please note that there is a list of open
> items at the end, which we plan to address in subsequent versions.

I have read draft-livingood-dns-redirect-00.  I have some (actually,
many) comments.  I write as a contributor of the DNS Operations
working group and not in any other capacity (especially not as co-chair
of DNSEXT).  I will leave it for others to debate the extent to which
the document actually proposes changes to the DNS protocol.  I
apologise for the length of this mail, but it seemed best to me to go
over the document in detail.

To begin with, I must state that I am opposed to adopting the draft as
it stands as a working group item with a target of BCP.  That said, I
agree that if people are going to do these sorts of things, it'd be
better that we have a document to explain what the least bad way to do
them is (although one might be excused for wondering what "least bad"
means in a context such as this).  It is a fact that people are doing
these DNS tricks, and we will not be saved from them by refusing to
talk about them any more than we were saved from the stupidest
possible NAT implementations by the IETF's collective refusal to work
on NAT.  Still, I am not sure that the document as it currently stands
represents that "least bad", so there's some work to do.

First, in section 3 we have a note that there are alternative
strategies to DNS redirects.  It is one thing to rule discussion of
those alternatives out of scope; it is quite another to present the
alternatives as completely neutral.  This discussion should be
strengthened to point out that performing redirects in the DNS have
extremely wide consequences, and that the DNS-based approach is a
terribly blunt instrument to perform what is intended to be surgical
redirections, akin to doing an appendectomy with a club.  In addition,
I think the discussion should point out that DNS-based redirection
violates the basic principle of the DNS: it is supposed to be a
distributed, loosely-coherent database of records originally provided
by authoritative sources of data.  DNS redirections violate that
principle by design, even if they do it for the noblest reasons.  This
is an important factor in the discussion of DNSSEC, to which I'll turn
near the end of this message.

I note this text in section 5.1.3:

   Design considerations for the Web Error Search and Malicious Site
   Protection services should include properly and promptly
   terminating non-HTTP connection requests.

I would find it helpful if the draft included some text explaining how
to terminate "non-HTTP connection requests" (and make a subsequent
connection request operate correctly)?  There's nothing in the DNS
request that would tell a resolver whether the DNS query was happening
because the client planned to make an http connection as opposed to
something else.  Is the idea to monitor DNS requests, then sniff the
traffic to see if it's an HTTP request and then do something with that
knowledge?  (This sounds just shy of practically impossible to me, but
I'd be happy to be wrong.)  What about https requests?  Surely,
malware people will quickly learn to send the requests via https if
that's a clear path, so that won't work.  And anyway, one can't sniff
encrypted traffic.

In section 5.2.3, it says

   A range of resource records may be redirected, such as A,
   AAAA, MX, SRV, and NAPTR records, in order to fulfill the objective
   of preventing access to certain network elements containing malicious
   content or which and in some way used to transmit, relay, or
   otherwise transfer malicious content.  All other resource record
   types must be answered as if there was no redirection.

I think the last sentence is just a rhetorical flourish.  It seems to
say that any RR may be redirected, depending on the objective; but
other ones must (MUST?  I suppose this depends on where one stands on
2119 language in BCPs.  If the authors want 2119 language, there are
some other places that could do with it too) be answered as if there
were no redirection.  This boils down to, "Redirect whatever you think
you need to."  So the last sentence in the quoted bit is just
decoration: it merely makes the passage read as though the technique
isn't too invasive, but it has no practical effect.  (Section 5.5 has
this, too.)

Section 5.3 ought to point out that legally-mandated DNS redirect may
do harm, because the ability to send desirable traffic (such as
cease-and-desist emails, for instance) is lost (this is especially
important in light of the discussion of proxy servers at the end of
5.3.3).  Section 5.3.3 reads like it was written by actual lawyers
(note that in my idiolect, "lawyer" is not automatically a term of
derision): there are here a lot of and/ors, other slashes, and lists
of possible authorities.  For readability, I suggest that this be made
simpler and more neutral.  "Legal authority" probably covers
everything needed to encompass the various kinds of agencies in
question.  I'm also not sure the apparent requirement to disclose that
the redirection is enforced by law has any practical value, although I
think it's nice if my ISP tells me it's fooling with the bits because
of law enforcement rather than local policy.

What is the interaction between the manual DNS server reconfiguration
discussed at the end of section 6.3, and the persistence
recommendation in section 6.1?  It seems to me all but inevitable that
a manual modification will bumped out of the way by a subsequent
automatic configuration unless the automatic system is informed of the
manual changes.  Therefore, it seems to me that there needs to be a
mechanism by which manual configuration changes can be communicated
back up to the automatic assigner, so that the manual changes don't
later get undone.  (It'd probably be enough to specify the ability to
disable the manual changes, without perhaps needing to send all the
new configuration to the ISP.)

In section 6.4, the text appears to suggest that setting an attribute
in the browser will affect how the DNS lookups happen.  I suggest
removing that text or else including a pointer to the section in which
you explain why it is a bad (not to say "ludicrous") idea.  The
subsequent text is the right direction to go: to allow users to opt
out, just change their network configuration.  I think some more
exposition of the tradeoffs may be needed, however, since the current
text seems to be fairly narrowly tailored to the present-era
arrangement where the CPE has a single IPv4 address with a NATted LAN
sitting behind it.  Given that some other participants in the IETF are
busily telling everyone to assign fairly large IPv6 ranges to every
customer, the model in the draft probably needs some more refining.

I think the discussion in 7.1 isn't drawing the wanted distinction
quite as clearly as it might.  The proposal is that a _good_
redirection captures the query, detects it is one of the redirection
targets, and takes the user to a web page where the user is told that
they've been redirected.  The complaint in 7.1 is really that the
very same redirection has happened, but the user is not informed.  The
discussion of "valid reason for the redirection" is just a
distraction: the issue isn't whether the redirection is somehow
justified (since there are some of us who would reply that such a
redirection is _never_ justified), but whether the user is told about
it.

Section 7.4 would benefit from some characterization of what would be
acceptable additional latency introduced by a redirector.  Citations
of user-experience studies would help.  It seems to me the section is
talking about one of the trade-offs to be made when trying to decide
whether to add a redirector, and without some well-founded numbers,
this is just hand waving.

Section 7.5 seems to suggest that there are cases where it is
acceptable to intercept DNS queries and redirect them silently.  These
cases are typified as being "reasonable", "justifiable", &c.  The
problem with any of this sort of thing is that it is the ISP who gets
to decide what is "reasonable".  I presume that those ISPs who are
capturing and blocking or, worse, redirecting all DNS traffic think it
_is_ reasonable and justifiable.  Since what is reasonable and
justifiable is right at the core of disagreement, reasonableness and
justifiability can't be the criteria.  I suggest that discussion be
removed: there just is no reason to capture the DNS traffic.  If you
want to turn someone off, _turn them off_.

Section 8 could be improved considerably by discussing the way that
redirection breaks other protocols.  A diagram that looks very like
(e.g.) Figure 5, only with no place in the protocol where the Web
response box goes, might make clearer why the redirection is
problematic.

Section 9.7 says, "This example represents an improper redirect
occurring when a valid DNS RR should have been returned in response to
a DNS recursive query for an example website, the resulting HTTP
transaction, and that no DNS query or HTTP traffic was sent to the
valid authoritative DNS server and valid web server."  This makes it
sound like there should be an HTTP request going to the DNS server.  I
know that's not the intent, but given that the target audience is
presumably confused about the relationship between DNS servers and web
servers (to the point that they're willing to break every other
application in the interests of supporting the web servers), this
should be cleared up.

Section 10's consideration of DNSSEC seems to have some fairly deep
misapprehensions of the DNS protocol.  First, it has a completely
naive idea of the actual DNS ecosystem.  It starts by shutting down
any discussion of non-stub resolvers on the grounds that "DNS
redirections take place on the recursive server", as though only one
recursive server could be involved in a resolution request from a
stub.  But previously in the draft there was some discussion of
networks in households, and so on.  One model of deployment there is
surely a gateway server that runs its own DNS recursive resolver, and
provides service to all the systems behind it, often with a single
IPv4 anddress and an RFC1918-addressed NAT.  Such gateways are obvious
targets for DNSSEC deployment.  Now, since they usually get the
address from the ISP via automatic means, they will get the DNS
configuration from the ISP.

There is nothing whatever about a given query that could tell you,
"Oops, this one's not from a stub; better give it the real DNS."  So,
the draft should address the case of a full-service recursing
validating resolver inside the redirect boundary.

It is interesting to compare bullet 2 with the advice we editors of
the DNS64 document (over in BEHAVE) have received.  In our case, the
suggestion has been that, if the security-aware translator validates
the answer from the DNS containing an A record, and is going to
provide the querying resolver (which set DO=1 and CD=0) an answer, it
is perfectly acceptable to set the AD bit in the answer.  This is
because of the language in RFC 4035: "The name server side SHOULD set
the AD bit if and only if the resolver side considers all RRsets in
the Answer section and any relevant negative response RRs in the
Authority section to be authentic."  In the case of DNS64/NAT64, the
trick here is to expand the definition of "authentic" to include the
NAT64 technique.  I suspect this is really acceptable to people
because the DNS64 knows about the NAT64 configuration, and is
attempting to hook the querying host up with the target host (and is
just compensating for the fact that the v4 and v6 networks are really
different networks).  But strictly, the justification for setting the
AD bit is that the DNS64 host knows about the NAT64 configuration, and
therefore is in a position to assert the authenticity of that address
(having assured itself of the authenticity of the destination address).

The redirection case is on purpose sending the querying client to some
target host _other than_ the requested one.  In some sense, then, the
decision in the draft not to set the AD bit on these responses is
praiseworthy.  However, the redirector presumably is tightly coupled
to the configuration of redirection and the host that is used to offer
landing pages.  Therefore it seems to me by the logic used above,
setting the AD bit would not strictly be a violation of the protocol,
if it isn't in DNS64.  I confess this conclusion makes me extremely
uncomfortable.  

I think a great deal of additional text will be needed to explain how
the ISP-provided "mitigating" trust anchor is supposed to help solve
the issue that the redirector's answers will fail validation by a
downstream validator.  Part of the point of DNSSEC is supposed to be
that we can prove delegations haven't been mucked with along the chain
between resolvers, and also that the trust across zone cut boundaries
is not broken.  This is the cryptographic assurance of the integrity
of the distributed database I mentioned at the beginning of this
message.  The goal of redirection is to subvert that integrity (never
mind whether it's justified -- that's the goal).  

The only way, it seems to me, that a redirector can use an alternative
trust anchor is to get its clients to accept an alternative (or,
rather, "additional") root key.  Then any validation chain can be
produced using that key, at the cost of a considerable increase in
state on the part of the redirector (because presumably the redirector
is going to need to remember what queries need supporting keys chasing
all the way down from the root.)  If such a system could be built such
that it could be reliably deployed, it would amount to a frontal
assault on DNSSEC itself, and on the principle of the single root.

And so we arrive at the really fundamental problem of the draft: it
presents a plan to fracture the namespace selectively.  Sometimes,
just in cases reflected in the redirector's own configuration, the
namespace delegation points are _not_ those as reflected in a common
hierarchy descended from a root (let's leave aside the "unique root"
for the moment, since it's not precisely relevant to this argument),
but instead a delegation to some other point.  Under such a model, a
coherent distributed database becomes totally unreliable.  We might
say DNSSEC is designed to foil the sort of attempt redirection makes
precisely because this kind of fracturing undermines the database
itself, and that the result of being able to prove you've arrived at
the right host is just a happy instantiation of the more general
principle.

It is therefore mind-boggling that there is nothing in the Security
Consideration sections of the draft to say, "Oh, and we've broken the
DNS Security Extensions, too."  Section 11 also includes the following
text, which probably needs to say "no-one" where it says "someone":

   Security best practices should be followed regarding access to the
   opt-in and opt-out functions, in order that someone other than the
   user is able to change the user's DNS Redirect settings.

These are all the remarks I have at the moment.

Best regards,

Andrew

-- 
Andrew Sullivan
[e-mail]
Shinkuro, Inc.