Hi Ted, On Mon, Jul 20, 2015 at 8:03 AM, Ted Lemon <ted.le...@nominum.com> wrote: > > I sent this out on July 20, but unfortunately just to Paul Hoffman. I was > puzzled as to why it didn’t get any response on the mailing list, but this > explains it… :}
Your headers still seem a bit messed up as when reply-all in gmail to your message, it was only going to send it to Paul Hoffman. I had to add the DNSOP WG manually. > ... > > The document describes several attacks, and describes a mechanism for > mitigating them. The method described seems as if it would function. > However, I don’t see any way in which the proposed method actually mitigates > the attacks that are described in the document. See below. > I also don’t see whether there are incentives for anybody to implement it. > So I actually oppose publication of the document as a standard, because it’s > going to wind up on some RFP checklist, and we’re going to have to implement > it, but I don’t see how it’s actually going to help anyone. So, you say people won't implement it and we shouldn't make it a standard because if we do people will implement it?? Again see below regarding the benefits of COOKIEs. > To expand a bit on this, the document describes two attacks that this method > is intended to mitigate: DDoS and Cache poisoning. Let’s consider how the > proposed mechanism would work for these. > > For DDoS, the cache or auth server is presumably going to decide whether to > process a request based on whether the resolver on the client sent the right > cookie. An attacker can’t receive the server cookie, so it can’t send it. Typically servers currently have a variety of heuristics to decide whether to process a request. Cookies are a cheap way to provide them with more information. Also, when you get a request with just a client COOKIE, a server has the option to fire off a short BADCOOKIE error reply which avoids the burden of actually processing the request and bootstraps the zero-configuration mode of the COOKIE mechanism. > This sounds great in theory, but now we have the server processing cookies in > order to avoid processing something else. Right, but COOKIEs are very light weight, a lot less than processing most queries. And, compared with TSIG, which provides strong authentication where COOKIEs provide weak authentication, the computational effort involved with reasonable COOKIEs is three or more orders of magnitude less than TSIG as well as not requiring the pre-configuration of TSIG although the benefits of COOKIEs can be increased with configuration. (In fact, if you had TSIG implemented and configured, you would want COOKIEs so as to filter out a lot of requests before doing more burdensome TSIG calculations (unless you had a TSIG algorithm with build in COOKIEs which I don't think any have).) > And this requires that all query sources support cookies; if they don’t, you > don’t get any benefit, but you still get the cost. I don't understand this. If a client does not support COOKIEs, you have exactly the current situation. There is no run time cost. If any client does support COOKIEs, you have more information when you process requests from that client and thus can make better decisions about how to respond. So you get a benefit if any client supports COOKIEs. (If all the clients you are interested in support COOKIEs, then you could configure to automatically discard any request without an OPT or with an OPT but no COOKIE but, at least in the near term, this seems likely to only be applicable in closed environments.) > So is there some basis for thinking that we would see widespread support for > DNS cookies on all resolvers? I find this unlikely. So we’ve actually > created a new problem, rather than solving an old problem. I would agree that universal deployment of pretty much anything on the Internet takes a long time. :-) But with COOKIEs, the more widespread the deployment, the more benefit. I don't understand what new problem has been created. > For cache poisoning, who are we protecting? The document says that we are > protecting the resolver, which could either mean the stub resolver on the > client or the caching resolver. So I’m going to assume we mean the caching > resolver. I suppose the theory here is that there is an incentive for auth > servers to implement DNS cookies, and if they do we can avoid attacks, but > again I’m not clear on how this is expected to work in practice. In > practice we see that DNS server conformance by server providers is pretty > abysmal. If it were the case that we had some way to know in advance that a > particular auth server supported cookies, maybe that would work, but we don’t. Earlier versions of this draft had optional configuration to an "enforced" mode but defaulted to an "enabled" mode where the client remember when it had seen a response from a server with a server cookie as soft state. See, for example, Section 6 of https://tools.ietf.org/html/draft-eastlake-dnsext-cookies-04 This was taken out to simplify the draft but something like it could certainly be added back in, perhaps with improvements, if it was thought worthwhile. > So what we wind up with is that the caching resolver now needs to maintain a > list of auth servers, mark whether these authors support cookies, and discard > non-cookie responses to queries sent to those servers, in order to > incentivize auth server operators to support cookies. Part of the idea of COOKIE is that it can help with zero configuration. I would say that clients should learn dynamically, as soft state, whether servers support COOKIE, exactly as client now typically learn lots of other things about servers dynamically as soft state, like whether they support OPT. > Which sounds great until you consider that we now have a possible new DoS > attack. It’s a little hard to implement, because you need to be on-path, > but we’ve seen that being on-path isn’t really all that hard. So now I can > intercept a query to a site I want to attack, respond with a cookie, and now > that site is on the supports-cookie list. So if it doesn’t support cookies, > the cookie-supporting cache will see a server failure, and now that domain is > offline. There are very few features which have absolutely no negative aspects. If an attacker is on path and can block/corrupt your messages, your screwed. If an attacker is on path and can observe and inject traffic, COOKIEs are useless and you need something cryptographically strong like TSIG or DPRIVE. If an attacker is off path, COOKIEs are cheap and provide significant benefit by weakly authenticating requests to servers and responses to clients. Are you going to assume that the attacker or various tentacles of the attacker, are on path for every server for zones you are interested in? That seem like a pretty powerful attack to me -- they are either pretty local to you or are all over the place. > So we have to do a lot of work, and I guess we get a little protection, but > we have new risks. No one has to do anything. COOKIEs are optional and the more widely deployed they are the more protection. There is COOKIE code in BIND which will be tweaked to support the standard. I don't think implementing COOKIEs is that much work. > Whereas DNSSEC actually solves the problem. So if we are going to > incentivize people to implement something, why not incentivize them to > implement DNSSEC, rather than a very limited yet expensive half-measure? COOKIE are many orders of magnitude cheaper than DNSSEC but, of course, COOKIEs do not claim to provide the same protection as DNSSEC. DNSSEC only solves the cache poisoning attack and then only solves it completely if it is universally implemented in the clients and servers and universally configured in all zones. Because DNSSEC makes answers longer due to signatures and NSEC(3)(s) and because it often requires burdensome cryptographic calculations, DNSSEC makes denial of service attacks worse on forged client addresses and on server and client computational resources . Cookies are actually quite synergistic with DNSSEC. Because of the increased burdens of processing requests with DNSSEC, DNSSEC servers have an incentive to more strongly filter requests, for example by using COOKIES. And the increased amplification with DNSSEC makes filtering requests for probable authenticity more important. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
