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 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
