On Mon, Jul 13, 2009 at 09:20:12PM -0400, Livingood, Jason wrote:
Great and detailed feedback on our first draft, Andrew. I'll take a reply
in detail, point-by-point, when I start working on -01 with my co-authors
and contributors.
Thanks
Jason
jason
andrew pretty much covered it but just to be explicit,
my two biggest issues:
(1) for each proposed scenario, need to explain why not only is
it possible to incur some collateral benefits by falsifying
DNS responses, but why falsifying DNS responses is the Best
or Only way to achieve those benefits.
(2) especially given its legalistic tone, should acknowledge
that the legal territory this behavior occupies is unresolved,
and will likely be answered differently by different national
laws. somewhere near where you acknowledge explicitly "this does
violate the intended use of this protocol \cite{}, and here
are the bad things that can happen as a result."
k
On 7/13/09 4:29 PM, "Andrew Sullivan" <a...@shinkuro.com> wrote:
> 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
a...@shinkuro.com
Shinkuro,
> Inc.
_______________________________________________
DNSOP mailing
> list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
