Re: [DNSOP] Seeking more WG Last Call review for draft-ietf-dnsop-cookies

[Donald Eastlake <[e-mail]>]

Hi Ted,

On Mon, Jul 20, 2015 at 8:03 AM, Ted Lemon <[e-mail]> 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   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]