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

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Jul 2015 08:03:36 -0400

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… :}

On Jul 16, 2015, at 3:52 PM, Paul Hoffman <[email-masked]> wrote:
> 
> <secretary-hat on>
> 
> Greetings. The WG Last Call for draft-ietf-dnsop-cookies was supposed to end today, but it got extremely little review during the Last Call. It would be helpful to all of us if more people can review the document, say what they do or don't like about it, and so on.

I didn’t pay a lot of attention to this when it was being considered for adoption because it seemed notionally like a good idea, but I’ve now read the draft, and I’m rather confused.

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

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.   This sounds great in theory, but now we have the server processing cookies in order to avoid processing something else.   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.   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.

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.

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

So we have to do a lot of work, and I guess we get a little protection, but we have new risks.   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?

---

From: "Zhiwei Yan" <[email-masked]>
Date: Mon, 3 Aug 2015 09:46:20 +0800

-DDOS: the current situation is that it is very very easy to construct a DNS packet and then the bandwidth requirement to defend DDOS continuely increases. the additional cost will be introduced in the "cookies" scheme, but it will be more flexible in this case because it will be very easy to diffentiate the packets-with-cookies and packets-without-cookies, and the cost will be much lower compared with the DNSSEC. in this point, "cookies" is a light-weight scheme compared with DNSSEC.
-cache poison: DNSSEC is better to solve this problem compared with "cookies".

2015-08-03 

Zhiwei Yan 

发件人： Ted Lemon 
发送时间： 2015-08-01  22:36:03 
收件人： Paul Hoffman 
抄送： 
主题： Re: [DNSOP] Seeking more WG Last Call review fordraft-ietf-dnsop-cookies 
 
I didn’t pay a lot of attention to this when it was being considered for adoption because it seemed notionally like a good idea, but I’ve now read the draft, and I’m rather confused.
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.   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.
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.   This sounds great in theory, but now we have the server processing cookies in order to avoid processing something else.   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.   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.
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.
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.   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.
So we have to do a lot of work, and I guess we get a little protection, but we have new risks.   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?
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Hosnieh Rafiee <[email-masked]>
Date: Mon, 03 Aug 2015 10:14:35 +0200

On , Zhiwei Yan wrote:
> 
> 
> -DDOS: the current situation is that it is very very easy to construct
> a DNS packet and then the bandwidth requirement to defend DDOS
> continuely increases. the additional cost will be introduced in the
> "cookies" scheme, but it will be more flexible in this case because it
> will be very easy to diffentiate the packets-with-cookies and
> packets-without-cookies, and the cost will be much lower compared with
> the DNSSEC. in this point, "cookies" is a light-weight scheme compared
> with DNSSEC.

Depends on what the definition of DoS attack is. only the client side 
mechanism (can be anything, either cookie or simplest one) can mitigate 
DoS attack on client. But the server side, IMO, cannot do much help as 
far as they explained in the draft.

in very special scenario, what it can do is only convert DNS 
amplification attack to DNS reflection attack which is again a kind of 
DoS attack on client. If the client implemented DNS client mechanism 
(whatever, it can be or only by keeping the track of its communication 
to server or we say e.g. client cookie where this cookie is only kept in 
client and not sent to server) then either it is DNS amplification 
attack or reflection attack, the client machine behaves the same way and 
drops all messages that it haven't requested. So, implementation of 
server side doesn't change this.

Because, the server does not create the same cookie for client since the 
server secret might be different for new request. Therefore, 
server_cookie1<>server_cookie2 that is generated for the same IP address 
and might be also with the same client cookie. Therefore there is no 
authentication in server side.
If we also assume that server keeps the IP address of the client and its 
binding to cookies for a short time in server's memory, it is the same 
as when server only keeps the IP address of client and does not accept 
any further request that comes immediately from the same IP address or 
does not accept more than 2 or 3 request per seconds.
So either server go to generates cookie or not, by only keeping the IP 
address and give it a time limit, can transfer DNS amplification attack 
to reflection attack that in both cases, as I explained before, client 
behave it the same way(as Alice either eats all the cookies or say she 
has on diet and drop them :-) )

Furthermore, the usefulness of the server side part of that is 
conditional. This means the adversary also cannot sniff his own messages 
sent to a DNS server so that it also includes server cookie generated as 
an answer to the adversary's cookie with fake source iP address.

This is really a strong assumption that in reality the situation is 
50/50 or less. So, the question is that does it worth to consider the 
"Server-side" of this mechanism as it is defined in the draft by 
considering the fact that it MIGHT only convert the DoS amplification 
attack to reflection attack that is again a kind of DoS attack on 
client?
Please note that the networks are not without any protection as the 
assumption of this draft is. In the network there are IPS, IDS and 
firewalls where mitigates such attacks on the networks. So, if adversary 
based on Alice IP in her email, started using that for attacking her, if 
Alice's IP belongs to enterprise, they did not left their network open 
to DoS attacks and let the adversary to target Alice that is inside this 
network.

Therefore, the next question is what is the purpose of the attacker to 
attack Alice who found her IP address by chance from the email and why 
should the adversary put efforts to do this? Who is this client that 
this mechanism wants to protect?

The new version of the draft also didn't address these questions or 
couldn't answer the previous concerns about their mechanisms.

Best,
Hosnieh

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 3 Aug 2015 16:57:58 -0400

Hi Ted,

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

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

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
 [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Aug 2015 23:11:41 -0400

On Aug 2, 2015, at 9:46 PM, Zhiwei Yan <[email-masked]> wrote:
> -DDOS: the current situation is that it is very very easy to construct a DNS packet and then the bandwidth requirement to defend DDOS continuely increases. the additional cost will be introduced in the "cookies" scheme, but it will be more flexible in this case because it will be very easy to diffentiate the packets-with-cookies and packets-without-cookies, and the cost will be much lower compared with the DNSSEC

I alluded to this in my response to Donald, but just to expand on it a bit, this is only possible if the vast majority of the stub resolvers are doing cookies.   Otherwise, responding to a DDoS attack in this way does exactly what the attacker wants: it disables DNS resolution for your domain or for your users.   So this is not a valid use case for the draft unless you can explain how sufficient deployment would occur.

To illustrate what I am talking about, Google was unwilling to deploy AAAA records for their servers until the number of hosts that were able to succeed in connecting with the AAAA records present was >99.7%, if I remember that presentation correctly.   This is a very, very high bar.   If you are under a DDoS attack, of course, you may be willing to settle for a lower rate of success, but I would expect cookies to hover well under 50% pretty much forever, because there is no incentive for the host operating system vendor to implement it in the stub resolver, and look how long it took to get WinXP numbers down.   And that’s not even taking into account all the broken middleware out there, e.g. DNS proxies on home routers.   So even if vendors implement it, when will end-users deploy it?

In practice, therefore, in order to deal with DDoS attacks like this, the server weathering the attack will have to maintain state about clients, so that it continues to serve clients that don’t support cookies.   So we have additional code on the server, the ultimate result of which is that the server does substantial extra work, not less work, increasing, not decreasing, the effectiveness of the DDoS attack.

It’s certainly true that if support for cookies were near 100% in clients, and were not blocked by middleware, we could in fact turn off stateful heuristics and see a benefit from cookies, but that’s a really big if.   The incentives are all in the wrong places here.

---

From: "Zhiwei Yan" <[email-masked]>
Date: Tue, 4 Aug 2015 13:22:18 +0800

Hi, Ted,
Yes, as you said, during this stage and the near future, the default support of "cookies" must be low.
Then the server will be "tired" to serve both "with-cookies clients" and "without-cookies clients".
But I personally do not agree that the "cookies" will burden the server more seriously. Look at DNSSEC, it costs more, but it was adopted because we have requirements on it. Also on "cookies", it is better to find its advantages and use it in the right place.
For example, if the bind or some other softwares chould set "cookies" as a optional configuration: do not use it in the normal case, and open it under attack. I mean it's better to use it when necessary as a light-weight guard for the DDoS attack.
BR,
Zhiwei

发件人： Ted Lemon 
发送时间： 2015-08-04  11:12:11 
收件人： Zhiwei Yan 
抄送： dnsop; Paul Hoffman 
主题： Re: [DNSOP] Seeking more WG Last Call reviewfordraft-ietf-dnsop-cookies

---

From: Mark Andrews <[email-masked]>
Date: Tue, 04 Aug 2015 18:20:07 +1000

In message <[email-masked]>, Ted Lemon writes:
> > a DNS packet and then the bandwidth requirement to defend DDOS continuely
> > increases. the additional cost will be introduced in the "cookies"
> > scheme, but it will be more flexible in this case because it will be very
> > easy to diffentiate the packets-with-cookies and packets-without-cookies,
> > and the cost will be much lower compared with the DNSSEC
>
> I alluded to this in my response to Donald, but just to expand on it a
> bit, this is only possible if the vast majority of the stub resolvers are
> doing cookies.   Otherwise, responding to a DDoS attack in this way does
> exactly what the attacker wants: it disables DNS resolution for your
> domain or for your users.   So this is not a valid use case for the draft
> unless you can explain how sufficient deployment would occur.

Cookie code has zero cost when responding to non cookie requests.

Returning BADCOOKIE to all invalid / no server cookie avoids the
entire lookup process and rate limiting code.

> To illustrate what I am talking about, Google was unwilling to deploy
> AAAA records for their servers until the number of hosts that were able
> to succeed in connecting with the AAAA records present was >99.7%, if I
> remember that presentation correctly.

No, Google was unwilling to return AAAA records to all hosts until
the number of hosts that weren't taking a multi-second connect
penalty dropped to < 0.03%.

Google returned AAAA to resolvers with a working IPv6 path with
very early.  Initially you requested that Google white list your
resolvers.

> This is a very, very high bar.
> If you are under a DDoS attack, of course, you may be willing to settle
> for a lower rate of success, but I would expect cookies to hover well
> under 50% pretty much forever, because there is no incentive for the host
> operating system vendor to implement it in the stub resolver, and look
> how long it took to get WinXP numbers down.   And that’s not even taking
> into account all the broken middleware out there, e.g. DNS proxies on
> home routers.   So even if vendors implement it, when will end-users
> deploy it?

Just recursiver server to authoritative server is reason enough to
deploy cookies.  Stub to recursive server would be better though
for many recursiver servers allow-recursion is enough.

> In practice, therefore, in order to deal with DDoS attacks like this, the
> server weathering the attack will have to maintain state about clients,
> so that it continues to serve clients that don’t support cookies.   So we
> have additional code on the server, the ultimate result of which is that
> the server does substantial extra work, not less work, increasing, not
> decreasing, the effectiveness of the DDoS attack.

No.

> It’s certainly true that if support for cookies were near 100% in
> clients, and were not blocked by middleware, we could in fact turn off
> stateful heuristics and see a benefit from cookies, but that’s a really
> big if.   The incentives are all in the wrong places here.

If you are under attack the current method drop or send back TC=1.  TC=1
means managing many more TCP session on both the server and client side.
With cookies it is drop or BADCOOKIE which keeps the traffic on UDP if there
isn't a good server cookie.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Aug 2015 11:47:51 -0400

> But I personally do not agree that the "cookies" will burden the server more seriously. Look at DNSSEC, it costs more, but it was adopted because we have requirements on it. Also on "cookies", it i…

Forgive me, but you have not explained why you don’t agree with me.   You’ve just said that you don’t agree with me.   While I respect your disagreement, the mere fact that you disagree with me is not something that the working group chairs can (or at least should!) weigh as part of their consensus call.

To recap, the reason that I think cookies are more expensive than DNSSEC in practice is that for cookies to be deployed in the real world, the DNS server implementing them will need to maintain state: the fact that a client has not presented a cookie cannot in itself be a reason to drop that client’s request.  DNSSEC does result in larger packets being sent, it’s true, but this is a relatively small load for the server, since these packets can be served directly out of the database, and don’t need to be computed, nor does special per-client behavior need to be implemented.

If you disagree with this analysis, could you please explain what I have gotten wrong?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Aug 2015 11:50:33 -0400

> isn't a good server cookie.

This is the current method BIND uses.   BIND is not renowned for its ability to weather DDoS attacks.   Your other assertions are false, and I already explained why.   You cannot drop no-cookie queries without increasing the effectiveness of the DDoS attack.

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 4 Aug 2015 12:30:13 -0400

Hi Ted,

On Tue, Aug 4, 2015 at 11:50 AM, Ted Lemon <[email-masked]> wrote:
> This is the current method BIND uses.   BIND is not renowned for its ability
> to weather DDoS attacks.   Your other assertions are false, and I already
> explained why.   You cannot drop no-cookie queries without increasing the
> effectiveness of the DDoS attack.

You have misinterpreted Mark's message. I don't think his message had
anything to do with always dropping no-cookie requests. (By the way,
the draft tries to be careful to use request and response since it
isn't just about queries.) I think Mark was pointing out that if you
are under attack and want to use weak authentication to help resist
that attack, there is no particular reason to push cookie supporting
clients to TCP to provide that authentication. COOKIEs provide weak
authentication roughly equivalent to TCP while continue to use less
burdensome UDP.

Thanks,
Donald

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 4 Aug 2015 12:35:10 -0400

Hi Ted,

On Tue, Aug 4, 2015 at 11:47 AM, Ted Lemon <[email-masked]> wrote:
>...
>
> To recap, the reason that I think cookies are more expensive than DNSSEC in
> practice is that for cookies to be deployed in the real world, the DNS
> server implementing them will need to maintain state: the fact that a client
> has not presented a cookie cannot in itself be a reason to drop that
> client’s request.  DNSSEC does result in larger packets being sent, it’s

There is nothing in this draft about the server maintaining state
other than its small server secret. The draft makes it clear that the
situation for requests without a COOKIE is the same as it is now. So,
COOKIEs don't help in the case of a client that doesn't implement them
except that the server sees that that client didn't implement COOKIEs
(or didn't implement OPT) and can take that into account in whatever
policy based determinations it makes whether or how often it
processes/discards requests or limits rates or replies suggesting TCP
or whatever. Why can't a server just provide degraded service to
client requests without cookies (which in some cases might mean
providing degraded service to forged requests claiming to be from a
cookie supporting client while providing better service for genuine
requests from that client)?

> true, but this is a relatively small load for the server, since these
> packets can be served directly out of the database, and don’t need to be
> computed, nor does special per-client behavior need to be implemented.

What about the cryptographic computations at the client? And the
problem with the much larger responses wasn't necessarily at the
server but at the client, which probably has a narrower pipe than the
server and may be getting sprayed with traffic from many servers.

Thanks,
Donald

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Aug 2015 12:39:46 -0400

On Aug 4, 2015, at 12:30 PM, Donald Eastlake <[email-masked]> wrote:
>  I think Mark was pointing out that if you

I think it’s a fair point that static cookies can be a more effective fallback than TCP, given the way TCP is generally implemented in host operating system stacks.   I’m not sure this is the best cure for that problem, however.   Essentially, you are fixing a transport layer problem with an app-layer kludge.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Aug 2015 12:43:28 -0400

On Aug 4, 2015, at 12:35 PM, Donald Eastlake <[email-masked]> wrote:
> other than its small server secret.

I know that.   The problem is that in order to avoid the negative consequences of DNS cookies when they are not widely implemented, you have to maintain state.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Aug 2015 12:45:50 -0400

> server and may be getting sprayed with traffic from many servers.

It might help if you could write up a clear analysis using real data that points to this as a concern.   As far as I know, it’s not.   Do people DDoS individual ISP customers?   I’ve been the _vector_ of a DDoS attack that _felt_ like a DDoS attack on me because they used all my bandwidth, but that was because I had an open resolver.   Literally within minutes of fixing the open resolver, the attack stopped.   I’m unaware of examples of end users being the victims of DDoS attacks where they weren’t running open resolvers.

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 4 Aug 2015 13:06:07 -0400

On Tue, Aug 4, 2015 at 12:39 PM, Ted Lemon <[email-masked]> wrote:
> I think it’s a fair point that static cookies can be a more effective
> fallback than TCP, given the way TCP is generally implemented in host
> operating system stacks.   I’m not sure this is the best cure for that
> problem, however.   Essentially, you are fixing a transport layer problem
> with an app-layer kludge.

No, it is not a "transport layer problem". It is simply an
authentication problem. It can be solved in various ways.

COOKIEs are an application layer solution against off path attackers.
TSIG is an application layer solution against on or off path
attackers. TCP is a transport layer solution against off path
attackers. TLS/DTLS is a transport layer solution agains on or off
path attackers. The stronger solutions which also protect against on
path attackers are inherently more expensive in requiring
cryptography, more configuration, prior agreement, and the like.

Thanks,
Donald

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 04 Aug 2015 12:01:18 -0700

> cryptography, more configuration, prior agreement, and the like.

+1 to Donald's response, and -1 to Ted Lemon calling cookies a "kludge". 
The same design has been in IKE and IKEv2 for decades for similar 
purposes, and it has worked just fine.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Tue, 4 Aug 2015 15:26:45 -0400 (EDT)

> I know that.   The problem is that in order to avoid the negative consequences of DNS cookies when they are not widely implemented, you have to maintain state.

I don't see that, despite you bringing this up a few times.

The server sends back a packet with cookie request and completely forgets
about the query. There is no state.

The confusion is introduced by the term "negative consequences of DNS
cookies when they are not widely implemented". If the client fails
to understand the packet, and it is a legitimate client, it will ask
again. If it is a botnet, it never sees the answer (and asks again anyway
because it is doing a a DDOS). If the legitimate client would not get
an answer because the server is about to topple over, it would also ask
again. So I do not understand what these "negative consequences" are.

However, if a client does understand cookies and the server receives
back a cookie, it can give that request a higher preference and answer
it in favour of sending cookie requests to clients that did not send
requests with cookies.

Paul

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Aug 2015 16:11:03 -0400

> it in favour of sending cookie requests to clients that did not send

Yes, but the cost is that you’ve doubled the number of packets exchanged, and the DDoS attacker gets a 50% amplification out of it.   It’s certainly cheaper than using TCP.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Aug 2015 16:20:15 -0400

> Yes, but the cost is that you’ve doubled the number of packets exchanged, and the DDoS attacker gets a 50% amplification out of it.   It’s certainly cheaper than using TCP.

Oops, no it doesn’t.   The only increase is in the number of packets sent to and from legitimate clients.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Aug 2015 16:21:25 -0400

> +1 to Donald's response, and -1 to Ted Lemon calling cookies a "kludge". 

Sigh.   The actual proposal, particularly the key rollover bit, is quite elegant, if a bit underspecified, so you’re right to call me out for this choice of terminology.   I called it a kludge because it is an attempt to use something that makes sense in one context in a different context where it won’t work very well.   It makes sense with IKE because you are preventing key spamming attacks from consuming massive amounts of CPU.   It wouldn't make sense to use in combination with TSIG because TSIG doesn’t use public keys.   In the particular use case that has been proposed,  it is pure speculation that it would actually deliver any benefit at all, but it’s pretty easy to enumerate the costs: twice as many packets sent to clients that don’t implement it, which will be most clients, and a number approaching twice as a limit as many packets for clients that _do_ support it, depending on how many of them are repeat customers.

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 4 Aug 2015 17:39:17 -0400

On Tue, Aug 4, 2015 at 4:21 PM, Ted Lemon <[email-masked]> wrote:
> Sigh.   The actual proposal, particularly the key rollover bit, is quite
> elegant, if a bit underspecified, so you’re right to call me out for this
> choice of terminology.   I called it a kludge because it is an attempt to
> use something that makes sense in one context in a different context where
> it won’t work very well.   It makes sense with IKE because you are
> preventing key spamming attacks from consuming massive amounts of CPU.   It
> wouldn't make sense to use in combination with TSIG because TSIG doesn’t use
> public keys.

It all depends on what algorithms you are using, how fast your
processor is, how close to saturation your processor is in processing
the request stream it is getting, whether it has hardware assist for
your algorithm, etc. I agree that there would typically be more
benefit for IKE than for TSIG. From that it does not follow that it
"wouldn't make sense" to use COOKIEs in connection with TSIG. The
non-cryptographic calculations you do for COOKIE verification are
going to be at least two orders of magnitude cheaper than the
cryptographic calculations you do for TSIG verification.

>                          In the particular use case that has been proposed,  it is
> pure speculation that it would actually deliver any benefit at all, but it’s

I would say it is more like it is easy to construct situations in
which it of great benefit and easy to construct situations in which it
is of no benefit. But it is not certain as to where on this spectrum
things will typically fall and how that will change with time.

> pretty easy to enumerate the costs: twice as many packets sent to clients
> that don’t implement it, which will be most clients, and a number

Since there is no change in behavior for clients that don't support
COOKIEs, there is no increase in packets for them.

> approaching twice as a limit as many packets for clients that _do_ support
> it, depending on how many of them are repeat customers.

I don't see any increase in packets for clients that support COOKIEs.
If a server does not think it is under attack and is getting few
enough requests from a client (and it seems to me that the first
request if it has no previous history of requests would always
qualify), it just processes the request normally and includes a server
COOKIE with the response. If, on the other hand, a server was going to
discard a request from a client then, in the case where the client
supports COOKIEs but did not include a correct server COOKIE, the
server can return a short BADCOOKIE response, which means the client
will be authenticated on its next try so that that client won't send a
series of retries that are discarded saving on traffic.

Thanks,
Donald

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Aug 2015 18:15:43 -0400

On Aug 4, 2015, at 5:39 PM, Donald Eastlake <[email-masked]> wrote:
> From that it does not follow that it

This is not true, because TSIG is going to be using the exact same hashing algorithm you are going to be using for cookies.   Kind of a side issue, though.

> things will typically fall and how that will change with time.

Actually we can make a lot of predictions.   First, if there is no incentive to implement it, vendors won’t implement it, so we can safely assume that adoption on stub resolvers will be very slow.  It’s possible that this could go a different way, but if history is our guide it won’t.   There is a huge incentive for DDoS attackers to come up with ways to bypass and leverage it, though.   Let’s think through some cases (I’m going to channel the following analysis from a private exchange I had with someone at Nominum who has a lot more DNS fu than I do, so if it seems brilliant, he gets the credit, and if it seems stupid, it’s probably because I am a lousy medium):

Client good, no cookie: client treated normally, rate limited for excessive traffic (client may be broken but not malicious, still needs rate limit). 

Client evil, no cookie: client treated normally, rate limited for excessive traffic because malicious.

Client good, has cookie: client treated normally, rate limited for excessive traffic because might be broken.   You can treat clients that have cookie preferentially, but you still have to rate limit them since they may be broken.

Client evil, has cookie: client treated normally, rate limited for excessive traffic because evil.   If you treat good clients preferentially, you’re also treating evil clients preferentially.

You may be tempted to say “but the client is a DDoS client, so it won’t have a cookie.”   This is false, because the client may be an open resolver that implements cookies, and indeed open resolvers that implement cookies will now be specially favored as attack vectors.   And of course botnet attackers have legit IP addresses and use them, so again they can and definitely will implement cookies.   Worse, they can now make you do more work in order to rate limit them, because they can make up new cookies.   And if you rate limit by IP address as well as cookie, then you are doing the same amount of work as if you just rate limited, so cookies provide no benefit.

All of this goes for other potential sources of attack, like states and weak jurisdictions.

The recursive->auth path is easy to attack with two-way communication, so cookies don’t really help you here unless you also do per-source rate limiting, at which point cookies also don’t help you because they add no value if you are doing per-source rate limiting.

(Back to me…)   This doesn’t even get into the attacks you can do against a server that has the stateless implementation proposed in the draft.   In an implementation that does no per-source rate limiting, a botnet or open-resolver network that can do cookies can now shut out the vast majority of legitimate clients that do not do cookies.   So cookies now massively assist the attack, rather than slightly penalizing it.   And this is a very real concern, because such networks exist now, and can readily be turned to this new and more effective attack as soon as cookies are widely deployed on caching resolvers and/or auth servers.   We are much more likely to see client-side cookie implementations on botnet attackers in particular because there is a huge incentive for implementing them.

And of course as I mentioned previously, an on-path attacker can _prevent_ resolvers that do not implement cookies from returning results to clients that do, and can prevent clients that implement cookies from talking to resolvers that implement cookies.   The only clients that are safe from this attack are clients that do not implement cookies, which is another reason why deployment of cookies on clients might be slower than you would like to anticipate.

> COOKIEs, there is no increase in packets for them.

Yup, sorry—I figured that out after I’d sent that response.

> COOKIE with the response.

We really don’t care about the non-DDoS attack case except to the extent that cookies could be pre-seeded to cookie-aware clients, both good and evil, so that they immediately get preferential treatment during DDoS attacks.

> If, on the other hand, a server was going to

This is true, but as explained above does not actually help.  I would suggest that it’s actually more likely that _all_ of the clients that implement cookies will be botnet clients, than it is that there will be a mix of botnet clients that implement cookies and legitimate clients that implement cookies, because botnets have an incentive to implement cookies, and legitimate clients do not.   It is an absolutely _huge_ win for a botnet attacker to implement cookies if most clients do not.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 05 Aug 2015 13:36:14 +1000

In message <[email-masked]>, Ted Lemon writes:
> This is not true, because TSIG is going to be using the exact same
> hashing algorithm you are going to be using for cookies.   Kind of a side
> issue, though.

And not true.  BIND uses AES if it is available.

> Actually we can make a lot of predictions.   First, if there is no
> incentive to implement it, vendors won’t implement it, so we can safely
> assume that adoption on stub resolvers will be very slow.

Well there are multiple vendors who have stated they intend to implement.

>  It’s possible
> that this could go a different way, but if history is our guide it won’t.
>   There is a huge incentive for DDoS attackers to come up with ways to
> bypass and leverage it, though.   Let’s think through some cases (I’m
> going to channel the following analysis from a private exchange I had
> with someone at Nominum who has a lot more DNS fu than I do, so if it
> seems brilliant, he gets the credit, and if it seems stupid, it’s
> probably because I am a lousy medium):
>
> Client good, no cookie: client treated normally, rate limited for
> excessive traffic (client may be broken but not malicious, still needs
> rate limit).
>
> Client good, has cookie: client treated normally, rate limited for
> excessive traffic because might be broken.   You can treat clients that
> have cookie preferentially, but you still have to rate limit them since
> they may be broken.
>
> Client evil, has cookie: client treated normally, rate limited for
> excessive traffic because evil.   If you treat good clients
> preferentially, you’re also treating evil clients preferentially.

The analysis above is lacking.

"has cookie" is not the determining factor.  "has good server cookie"
is the determining factor. 

Now without cookies you can't determine the difference between 1
and 2.  With cookie you can determine the difference between 3 and
4.  Additionally how you treat 1 and 2 is different to how you tread
3 and 4.

> You may be tempted to say “but the client is a DDoS client, so it won’t
> have a cookie.”   This is false, because the client may be an open
> resolver that implements cookies, and indeed open resolvers that
> implement cookies will now be specially favored as attack vectors.   And
> of course botnet attackers have legit IP addresses and use them, so again
> they can and definitely will implement cookies.   Worse, they can now
> make you do more work in order to rate limit them, because they can make
> up new cookies.   And if you rate limit by IP address as well as cookie,
> then you are doing the same amount of work as if you just rate limited,
> so cookies provide no benefit.

No so.  With cookies you by IP address no cookie, IP address bad/no
server cookie, IP address (or by client cookie) good server cookie.

The attack traffic falls into bins 1 or 2.  Legitimate repeat cookie
client traffic falls into bin 3.  Now most legitimate clients are
not broken so the chance of them being rate limited is low.  Clients
which don't implement cookies take all the negative consequences
of being binned with attack traffic.

> The recursive->auth path is easy to attack with two-way communication, so
> cookies don’t really help you here unless you also do per-source rate
> limiting, at which point cookies also don’t help you because they add no
> value if you are doing per-source rate limiting.
>
> (Back to me…)   This doesn’t even get into the attacks you can do against
> a server that has the stateless implementation proposed in the draft.
> In an implementation that does no per-source rate limiting, a botnet or
> open-resolver network that can do cookies can now shut out the vast
> majority of legitimate clients that do not do cookies.

Hogwash.  Where does anyone say not to service non cookie traffic.  You
are making this up in you head.

>   So cookies now
> massively assist the attack, rather than slightly penalizing it.   And
> this is a very real concern, because such networks exist now, and can
> readily be turned to this new and more effective attack as soon as
> cookies are widely deployed on caching resolvers and/or auth servers.
> We are much more likely to see client-side cookie implementations on
> botnet attackers in particular because there is a huge incentive for
> implementing them.
>
> And of course as I mentioned previously, an on-path attacker can
> _prevent_ resolvers that do not implement cookies from returning results
> to clients that do, and can prevent clients that implement cookies from
> talking to resolvers that implement cookies.  The only clients that are
> safe from this attack are clients that do not implement cookies, which is
> another reason why deployment of cookies on clients might be slower than
> you would like to anticipate.

> We really don’t care about the non-DDoS attack case except to the extent
> that cookies could be pre-seeded to cookie-aware clients, both good and
> evil, so that they immediately get preferential treatment during DDoS
> attacks.
>
> This is true, but as explained above does not actually help.  I would
> suggest that it’s actually more likely that _all_ of the clients that
> implement cookies will be botnet clients, than it is that there will be a
> mix of botnet clients that implement cookies and legitimate clients that
> implement cookies, because botnets have an incentive to implement
> cookies, and legitimate clients do not.   It is an absolutely _huge_ win
> for a botnet attacker to implement cookies if most clients do not.

Actually there are good reasons for clients to implement cookies.
They reduce the amount of port randomisation that needs to happen
in a recursive server (if the server supports cookies you don't
need to randomise the source port) and client cookies work even
when the NATs undoes port randomisation.

Even when the client does DNSSEC validation this is useful as the
referral is not signed.

---

From: "Ralf Weber" <[email-masked]>
Date: Wed, 05 Aug 2015 10:58:56 +0200

Moin!

> is the determining factor.
For the attack that Ted describes later these attackers will have a 
good server cookie as they are behind open resolvers that implements
cookies, so I think his analysis is correct.

But lets focus on the way the server handles cookies. I think I 
discussed that with you or Donald in Prague. There are two ways to 
do this so that each client gets a different cookie, which is what
the draft suggest:
- provide a total random cookie for each client. That way you have
to keep state for every client making it very easy to exhaust the 
server by sending different cookie requests from different addresses
(spoofed or as part of a /64 every IPv6 user gets)
- provide a deterministic function that takes the client IP and a 
secret to generate the cookie. That way you can generate the same 
cookie on every request.
So the last method becomes a cryptoanalytics problem and I am not
a cryptographer, but it would be good if someone with more know
how there could comment on how difficult it would be to break the
secret given that one can easily generate 2^64 different inputs
to that function and examine the output.

As soon as the attacker knows the secret he can spoof request from
any address with correct cookies rendering the cookie protection
useless. 

> when the NATs undoes port randomisation.
If NAT leaves the DNS packet untouched. I'm not sure they do this 
and most home gateways or firewalls have a DNS proxy anyway.
Also I don't want to get back to source and destination port being
53 it was quite a journey get various parties convinced that multiple
ports above `1024 are ok as source ports for DNS. 

> Even when the client does DNSSEC validation this is useful as the
Sure, but we would catch that with checking the DS against the keys.

So long
-Ralf

---

From: Mark Andrews <[email-masked]>
Date: Wed, 05 Aug 2015 20:50:02 +1000

> secret to generate the cookie. That way you can generate the same

Read the draft.  It does not say that.  It is IP address + client
cookie + secret (min 64 bits) + whatever else the server adds to
the mix (for named that is time + a 32 bit nonce).   It's also why
the secret needs to be updated periodically for the plain 64 bit
secret.

Thats 32 + 64 + 64 bits of input minimum.  For named it has at least
64 bits of input and possibly 96 more bits on top of that.

> and most home gateways or firewalls have a DNS proxy anyway.

If you are talking to the CPE as a nameserver.

If you are talking to remote nameservers (e.g. 8.8.8.8) through the
NAT you normally just have port manipulation. 

> ports above `1024 are ok as source ports for DNS.

So you leap from random ports to fixed port 53.

> Sure, but we would catch that with checking the DS against the keys.

Much better to not to have to detect and recover from being garbage
nameservers and addresses in the first place.

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 05 Aug 2015 08:05:23 -0700

> cookies, so I think his analysis is correct.

If an attacker is causing a system that does cookies to be an attack 
vector, then this proposal does no harm or good. The assumption in the 
proposal is that some of the attack traffic will continue to look like 
it has for the past decade, coming from non-attack systems that have 
been updated or from attack systems that have not been updated.

An earlier response to the proposal is, in essence, "no one will 
implement this because it won't do any good and might do a bit of harm". 
Others on the list have shown that they are interested in implementing 
this.

It might be attractive to say "there can be no possible help to the DDoS 
problem other than professional networking services that are seen 
today", but so far the WG has not agreed with that. This proposal gives 
those who cannot afford such services a chance to respond to a DDoS in a 
way that might help.

--Paul Hoffman

---

From: Paul Vixie <[email-masked]>
Date: Wed, 05 Aug 2015 09:42:20 -0700

Mark Andrews wrote:
> ...
>
> Read the draft.  It does not say that.  

t-shirt idea!

-- 
Paul Vixie

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Aug 2015 14:05:51 -0400

> Well there are multiple vendors who have stated they intend to implement.

Who?

> is the determining factor. 

That’s what “has cookie” means.

> 4.  Additionally how you treat 1 and 2 is different to how you tread

How can you tell the difference between an evil client and a good client based on the cookie?

> server cookie, IP address (or by client cookie) good server cookie.

I’m sorry, but I can’t parse that.   Can you restate it?

> of being binned with attack traffic.

I don’t see any mention of bins 1, 2 and 3 in the draft.   Can you explain what you mean?

> are making this up in you head.

If you are preferentially responding to cookie traffic, then if you are being DDoS’d by someone who has implemented cookies, every single non-cookie client is going to get swamped.   Some may get their queries answered, but most won’t.   If you are not preferentially responding based on cookies, then what’s the point of using cookies?   Also, could you please not use pejorative terms like “hogwash”?   If you disagree with me, all you need to do is point out my error.

> when the NATs undoes port randomisation.

The isn’t mentioned in the draft.

> Even when the client does DNSSEC validation this is useful as the

If you mean that the packet containing the referral is not signed, and that only the data it contains is signed or not signed, then I agree.   The problem is that this isn’t an argument in favor of cookies: if cookie work, then you don’t need this argument, and if, as I am claiming, cookies are harmful, then the fact that they happen to help you in this case isn’t much good.

Cookies can definitely help to prevent spoofing in the case of an off-path attack like Dan’s, but the damage they do is far worse than the benefit they offer.  I think if cookies were used just for this one case, it would be a lot easier to justify them, but this doesn’t seem to be the primary motivation for using them, and the DDoS case, plus the fact that they aid massively in on-path attacks, is a real problem.   Unfortunately I don’t see a way to mitigate the on-path attack other than DNSSEC.

---

From: "Ralf Weber" <[email-masked]>
Date: Wed, 05 Aug 2015 20:14:56 +0200

Moin!

> 64 bits of input and possibly 96 more bits on top of that.
It still is a function which outputs, if I read the draft correct, a
static cookie for at least a day. If during that day an off path
attacker can get a hold of the cookie he can use that cookie and the
spoofed address to overload the server.

> If you are talking to the CPE as a nameserver.
That still is the most commonly used use case AFAIK.

> NAT you normally just have port manipulation.
That is true for most home gateways. I'm not sure if this is true
for corporate firewalls, it certainly wasn't for me in my past jobs.

> So you leap from random ports to fixed port 53.
OMG lets hope that this doesn't happen. This would mean that all the
crap that still is out there that still has it has no reason to be
changed...

When I did a test a couple of months ago port 53 still was the most
prominent client port being used for about 1% of the queries.

> nameservers and addresses in the first place.
Then why didn't we do that in the first place. IMHO all the additional
"security" parameters you want to put into cookies make it more valuable
to get a hold of a cookie and use it to do bad stuff.

So long
-Ralf

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Aug 2015 14:15:43 -0400

On Aug 5, 2015, at 11:05 AM, Paul Hoffman <[email-masked]> wrote:
> If an attacker is causing a system that does cookies to be an attack vector, then this proposal does no harm or good. 

Can you explain why this is the case?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Aug 2015 14:16:42 -0400

> t-shirt idea!

Want.

---

From: "Ralf Weber" <[email-masked]>
Date: Wed, 05 Aug 2015 20:35:46 +0200

Moin!

On 5 Aug 2015, at 17:05, Paul Hoffman wrote:

> vector, then this proposal does no harm or good.
I have to disagree here. You are introducing additional complexity into 
the server which now has to handle two possibly three rate limiter with 
tables of counters to keep track of things with different algorithms 
what to do. And in the end you still want to answer as many queries as 
possible so you can't simply turn off non cookie traffic or rate it very 
low.

> It might be attractive to say "there can be no possible help to the 
> DDoS problem other than professional networking services that are seen 
> today", but so far the WG has not agreed with that.
I'm not agreeing with that either, but I am saying that for most of the 
attacks that this draft wants to protect against the operational 
community has found a way to deal with them.

> This proposal gives those who cannot afford such services a chance to 
> respond to a DDoS in a way that might help.
Which would only work in a vast or universal deployment which we know in 
the DNS won't happen fast. Heck we still have a sizeable chunk of severs 
not supporting EDNS0 after how many years now.

So long
-Ralf

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Aug 2015 15:31:28 -0400

> The isn’t mentioned in the draft.

Actually it is mentioned in the draft—my stupid search just didn’t find it.   Sorry about that.   The discussion in the draft assumes that an attacker on the wire would be unable to snoop and then use a legitimate client’s cookie.   This isn’t a valid assumption.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 5 Aug 2015 22:29:09 +0200

On Mon, Jul 20, 2015 at 08:03:36AM -0400,
 Ted Lemon <[email-masked]> wrote 
 a message of 72 lines which said:

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

This attack requires to be on-path *and* to be active (sending
responses). In that case, you don't need cookies to do harm, just send
SERVFAIL or REFUSED responses and the resolver will stop querying the
victim (the authoritative server).

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

DNSSEC has a limit: it *detects* the false responses, it does not give
you the right one. Instead of being hijacked, the domain is DoSed. It
is an improvment but it is not sufficient. We still need channel
protection, such as SPR and/or cookies and/or TCP.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Aug 2015 16:35:23 -0400

> victim (the authoritative server).

The cookie attack works for caching servers too.  And it’s not clear to me that any stub resolver would remember a REFUSED.   But yes, if you have a caching resolver going to an authoritative server, I suppose that what I’m describing is not a novel attack.

> protection, such as SPR and/or cookies and/or TCP.

You assert that we need channel protection, which is debatable, but I am arguing that even if we need channel protection, cookies don’t actually provide it.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 5 Aug 2015 22:32:32 +0200

On Tue, Aug 04, 2015 at 06:15:43PM -0400,
 Ted Lemon <[email-masked]> wrote 
 a message of 312 lines which said:

> because the client may be an open resolver that implements cookies,
> and indeed open resolvers that implement cookies will now be
> specially favored as attack vectors.

The vast majority of open resolvers are broken CPE, with a poor and
limited implementation of DNS, or very old BIND not maintained for
years. I think it's unlikely they will be upgraded to support cookies.

> And of course botnet attackers have legit IP addresses and use them,

If you do a reflection attack, or a poisoning attack, you cannot use
your legit IP address.

---

From: "Ralf Weber" <[email-masked]>
Date: Wed, 05 Aug 2015 23:06:22 +0200

Moin!

> years. I think it's unlikely they will be upgraded to support cookies.
But most of this broken CPEs forward to ISP resolvers and these will
eventually support cookies and forward the queries to the cookie
enabled authorities.

So long
-Ralf

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Aug 2015 17:25:58 -0400

> years. I think it's unlikely they will be upgraded to support cookies.

Right, but it wouldn’t surprise me to see a broken CPE in the future that implements cookies if they do catch on, so this is only comforting in the short term.

> If you do a reflection attack, or a poisoning attack, you cannot use

True.   What I describe only works for attacks where the bots or open resolvers themselves are sending the packets.   If that one objection were the only problem with this proposal, you might say that it’s worth doing for the sake of mitigating the two other attacks you mentioned.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 06 Aug 2015 11:39:48 +1000

In message <[email-masked]>, "Ralf Weber" write
> possible so you can't simply turn off non cookie traffic or rate it very 

If the attacker has a good cookie then you have a high degree of
confidence that the IP address is correct even if it a UDP request
and you can take steps like contacting the operators of the network
/ server.  You can also just block requests from the address knowing
that you are not harming someone else sans NAT'd traffic.

But hey, you obviously don't want to be able to know that or do that.

> not supporting EDNS0 after how many years now.

99.71% of TLD/Root servers support EDNS
96.07% of the Alexa top 1000 support EDNS
91.22% of the Alexa bottom 1000 of the top 1M support EDNS
98.08% of the GOV servers in the top 1M support EDNS
96.08% of the AU servers in the top 1M support EDNS

By my book that is vast but not universal.  The figures are also improving.

---

From: 神明達哉 <[email-masked]>
Date: Fri, 7 Aug 2015 10:57:24 -0700

At Wed, 05 Aug 2015 10:58:56 +0200,

> do this so that each client gets a different cookie, which is what
[...]
> to that function and examine the output.

Do you mean it might be easy to brute-force all 2^64 possible secrets
for, e.g, HMAC-SHA256?  Or do you mean it might be possible to attack
(e.g.) the HMAC-SHA256 algorithm so the attacker can identify the
secret from the 2^64 possibilities in much shorter time (such as a few
hours)?

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Fri, 7 Aug 2015 11:40:02 -0700

On Thu, Jul 16, 2015 at 12:52 PM, Paul Hoffman <[email-masked]> wrote:
> <secretary-hat on>
>
> Greetings. The WG Last Call for draft-ietf-dnsop-cookies was supposed to end
> today, but it got extremely little review during the Last Call. It would be
> helpful to all of us if more people can review the document, say what they
> do or don't like about it, and so on.

I've read draft-ietf-dnsop-cookies-05 (a post-WGLC version).

It basically looks good to me to ship: I agree the idea is at least
worth trying, and I see the document is generally well written.

I have some comments and questions that I think may be worth
discussing, however:

- About applicability: I see it can be a useful supplemental measure
  for cache poisoning.  Whether it really helps mainly depends on
  whether the authoritative server operators have an incentive to
  enable it, which I really don't know, but I believe it's at least
  worth trying.  On the other hand, I'm not so sure about mitigating
  reflection/amplification type of DoS attacks.  I thought we've
  reasonably addressed this problem for authoritative servers with the
  surprisingly quick adoption and deployment of RRL (but I may be
  wrong, in which case I'm happy to be corrected).  And so in my
  understanding the main current issue is open resolvers.  But if we
  can expect these resolvers to be updated to support DNS cookies to
  the extent that they are not a main concern, I guess the problem
  would have been resolved much earlier with the support of default
  ACL for those resolvers.  This does not necessarily mean DNS cookies
  are useful for this type of attacks, so it may still be worth
  trying, but the scope of expected attacks can affect how tricky the
  server cookies need to be as described in Section 6.  So, while I do
  not necessarily request to limit the scope, it may be good if the
  draft provides some more detailed discussion on these points.

- Section 4.1

   In order to maintain the security properties of this protocol, a
   client MUST NOT use the same Client Cookie value for requests to all
   servers.

  Specifically what does this mean?  Does this mean, for example, the
  client generates a different cookie value for a different server
  (identified by its IP address) and maintain the cookie values per
  server basis?

- Section 4.2

   In order to maintain the security properties of this protocol, a
   server MUST NOT use the same Server Cookie value for responses to all
   clients.

  I'm also not sure how I should interpret this.  Can't we basically
  assume this condition is met because the server cookie contains (in
  some way) the request source address and client cookie?  Of course,
  a naive implementation of how to "contain" them could lead to the
  same server cookie value regardless of the difference of these
  values, but if this sentence tries to avoid such naiveness, I'd make
  the point clearer.

- Section 5.2.3

   Servers MUST, at least occasionally,
   respond to such requests to inform the client of the correct Server
   Cookie.

  By saying "occasionally", it could read (to me) as if it intends to
  mean maintaining per-client state.  While a server implementation
  could actually do that, I guess that's something that this draft
  wants to avoid to see.  If so, perhaps something like "randomly"
  instead of "occasionally" may be a better choice.

- Section 5.5

   Clients and servers MUST NOT continue to use the same secret in new
   requests and responses for more than 36 days and SHOULD NOT continue
   to do so for more than 26 hours. Many clients rolling over their

  It would be helpful if the rationale (if any) of these constant
  values (36 days and 26 hours) is explained.

- Section 5.5

   When a server or client starts receiving an increased level of
   requests with bad server cookies or replies with bad client cookies,
   it would be reasonable for it to believe it is likely under attack
   and it should consider a more frequent rollover of its secret.

  It's not very clear to me how a more frequent rollover helps in this
  case.  In such a case the attacker basically keeps trying random
  cookies (right?), so whether or not we do rollover more frequently
  the attacker's odds wouldn't be different.  Or, does this intend to
  minimize the risk in case an attacker actually identifies the valid
  cookie by the random try (by reducing the attackable window)?

--
JINMEI, Tatuya

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 7 Aug 2015 18:16:16 -0400

Hi,

> secret to generate the cookie. That way you can generate the same

The second option above is the only method described in the draft
except that you can easily throw in additional fields as shown in
Appendix B.2.

> to that function and examine the output.

Counting out 2**64 is not that easy. Assuming you can count once a
microsecond, it will take you about 600,000 years. Of course, you only
have to count through half the space on average and, since it is
suggested that a non-cryptographic function may be adequate, there are
analytical short cuts. This could do with some more analysis but if,
for example, the estimated effort to break a value with some short
cuts is a savings of a factor of 100,000, the expected time would be
40 months. This is all an engineering trade off. You can use a
stronger function or a bigger field but at some point, it is cheaper
for the attacker to use more computers to attack the network rather
than using more computers to cryptanalyze what the server is doing.
Typical cryptographic authentication systems these days usually like a
96 bit or larger authentication code.

> any address with correct cookies rendering the cookie protection

Until the server changes its secret, which the draft suggests it
should do daily subject to a +0% to -40% jitter. There is no
particular reason the server couldn't change its secret more often,
something like once an hour, and the draft suggests that the server do
that if it suspects it is under attack.

Thanks,
Donald

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 8 Aug 2015 10:19:34 -0400

Hi Jinmei,

> worth trying, and I see the document is generally well written.

Thank you.

>   (identified by its IP address) and maintain the cookie values per

The draft does not require a client to use any particular way to
generate Client Cookies as a function of server IP address. It just
says the function "SHOULD" be as strong as FNV. What if the client
just always sends a constant value for the Client Cookie? That would
provide little security because, for example, any server that got a
request from that client could copy to Client Cookie and use it to
forge responses to the client for any request to any server. So this
text prohibits a client from just sending a fixed value client cookie
to all servers.

It would be nice to require a client to send a different cookie to
every server, but, as you say, that is usually impractical without
excessive state in the client to remember what cookies it has sent to
what servers. Using the sort of hashing techniques in the draft, the
probability is high that a different cookie will be sent to every
server, but it is not guaranteed.

Actually, the wording in the draft doesn't seem that good. Perhaps it
should be more like

   "In order to provide minimal authentication, a client MUST send
client COOKIEs that will usually be different for any two servers at
different IP addresses."

>   values, but if this sentence tries to avoid such naiveness, I'd make

Can you suggest replacement text? You seem to understand what is being
said. As above, it could be reworded as

   "In order to provide minimal authentication, a server MUST send
server COOKIEs that will usually be different for clients at any two
different IP addresses or with different client COOKIEs."

>   mean maintaining per-client state.  While a server implementation

I don't know why you would think that.

>   instead of "occasionally" may be a better choice.

I don't think there is much difference between "randomly" and
"occasionally" but randomly implies some attempt at an actual
pseudo-random mechanism. "Occasionally" can be satisfied by a
pseudo-random mechanism but also by some simple rule like responding
to every tenth request or every Nth request for some reasonable N.

>   values (36 days and 26 hours) is explained.

The rational is cryptographic hygiene. The longer you use any secret,
the higher the probability it has been compromised. The specific
values are to be sure in one case that the secret will not be used for
much more than a month and in the other case for not much more than a
day. The numbers may seem a bit odd but are designed to allow for
weekends and holidays and time changes for daylight savings time and
the like. While I don't think these times should be any longer I'm not
sure the precise value is that important.

>   cookie by the random try (by reducing the attackable window)?

The more you re being attacked the higher the probability that one or
more such attacks will succeed. More rapid rollover decreases the
benefit to the attacker when an attacker succeeds.

Thanks,
Donald

---

From: 神明達哉 <[email-masked]>
Date: Mon, 10 Aug 2015 10:26:11 -0700

At Sat, 8 Aug 2015 10:19:34 -0400,

[...]
> client COOKIEs that will usually be different for any two servers at

It basically looks good to me.  One possible concern is that the term
"usually" is vague/ambiguous especially when used in the context of a
MUST.  So, if I were an author I'd add a sentence like this at the
risk of sounding too verbose: "Specifically how to make them usually
different is implementation dependent, but it should be generally good
enough to use a good hash function with the server address being a
part of its seed."

> different IP addresses or with different client COOKIEs."

Same comment as the previous point applies.

See below.

> to every tenth request or every Nth request for some reasonable N.

Right, so "randomly" is just one way to implement "occasionally" and
was too restrictive.  And it's related to the other point: one other
way to make it "occasional" is to keep a per-client counter and
respond to every Nth request for that client or something.  I wouldn't
be surprised if some implementor develops this specification that way
to meet this MUST, and I thought we wanted to avoid that to happen.
So we might emphasize that in an additional sentence, e.g., "However,
servers MUST NOT maintain per-client state to implement that in order
to prevent resource consumption attacks on that state".

> sure the precise value is that important.

I didn't mean the rationale about the very specific number like 36 or
26.  It was more about the sense of scale of these constants, e.g.,
"not more than a month".  But I'd leave it to you whether or how to
update the text to address this point.

> benefit to the attacker when an attacker succeeds.

Okay, so I interpret it as the answer to my question in the last
sentence is "yes".  I'd also leave it to you, but I'd personally
clarify that a bit more explicitly, e.g.:

    When a server or client starts receiving an increased level of
    requests with bad server cookies or replies with bad client cookies,
    it would be reasonable for it to believe it is likely under attack
    and it should consider a more frequent rollover of its secret.  This
    will help minimize the duration when the attack is successful even
    if the attacker happens to identify one valid cookie.

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Aug 2015 08:20:58 -0400

On Aug 5, 2015, at 9:39 PM, Mark Andrews <[email-masked]> wrote:
> / server. 

After some pretty intense criticism of this document, I went radio silent last week for two reasons.   The first is that Mark said this, and it caused me to rethink my position on the document.   The second is that my mail server exploded in a rather exciting way, and I spent the weekend writing an SMTP server so that I didn’t have to install Postfix again.

So the short response to this is that I can now see how the draft is useful, but I think the draft fails to communicate why it is useful, and communicates some things that it’s purportedly for that aren’t useful.   However, it may also be that I simply didn’t read it carefully enough.   So I want to give it another thorough read and possibly suggest some changes that I think would result in readers having a clearer understanding of what it does that it useful, and not coming away with the impression that it does other things that I think could actually be harmful, but at the very least are not useful.   I think the changes I would propose would be to the explanatory text, not to the specification.

I think it would be useful to consider these changes before concluding the WGLC, but I am sure that the authors would like to see forward progress, and I’m not notoriously a fast reviewer.   So I mention this for the chairs’ information, but have no real expectations as to what they might do in response.   Thanks to Mark and Donald for their patient responses to my questions.