Subject: [DNSOP] Summary of the two options in draft-ietf-dnsop-cookies?

From: Paul Hoffman <[email-masked]>
Date: Sun, 29 Mar 2015 10:30:09 -0700

Greetings again. Can one of you summarize the differences between sections 4/5 and 6/7 in the recent -01 draft? It seems that the error code processing in 4/5 might either be useful or overkill.

A related question for Don: how close are you to getting draft-eastlake-fnv published? For me, it is mandatory for that draft to be stable (and hopefully published) before we publish draft-ietf-dnsop-cookies in order to make developers comfortable in deploying cookies without possibly opening servers and clients to CPU DoS attacks.

--Paul Hoffman

---

From: Mark Andrews <[email-masked]>
Date: Mon, 30 Mar 2015 06:47:45 +1100

In message <[email-masked]>, Paul Hoffman writes
:
> Greetings again. Can one of you summarize the differences between
> sections 4/5 and 6/7 in the recent -01 draft? It seems that the error
> code processing in 4/5 might either be useful or overkill.

I can't think of a good use for the error codes which is why I
didn't add them to SIT.  They are in -01 so the group has the two
formats written down for evaluation.

BADCOOKIE 

The senarios I can see that would result in this being sent are:

a) The server is under attack
b) The client has a old cookie
c) Mismatched cookie generation between a anycast instances

and the client can retry with the cookie from the response
or stop sending cookies.

A legitimate client doesn't see the (a) responses.  
For (b) retrying should succeed.  That said tc=1 would also be just as
effective at triggering a retry.
For (c) you are likely to get dueling servers and not progress to
giving the client a valid response.  The client will have to maintain
a BADCOOKIE response counter and then fallback to not sending a COOKIE.

MFCOOKIE

The senarios I can see that would result in this being sent are:

a) The server is under attack
b) The client is badly coded

This should really be a FORMERR if the option length is invalid.

NOCOOKIE

This is just a more precise REFUSED and needs to be a rcode if we
need this level of precision.  Spontaneously adding a cookie opt
to a reply without one doesn't help clients that don't understand
cookies.  Additionally it will be decades before anyone could set
this on the Internet.
 
> A related question for Don: how close are you to getting
> draft-eastlake-fnv published? For me, it is mandatory for that draft to
> be stable (and hopefully published) before we publish
> draft-ietf-dnsop-cookies in order to make developers comfortable in
> deploying cookies without possibly opening servers and clients to CPU DoS
> attacks.
>
> --Paul Hoffman
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 29 Mar 2015 18:38:24 -0400

Hi,

I've made some progress on the FNV code. I expect to be able to
advance it, presumably as AD sponsored, before the next IETF.

On DNS Cookies errors, I agree that the utility of the error field, as
far as we can see right now, is quite limited. Still, there can be
error conditions in the Cookies in queries when the server decides to
go ahead and provide a normal full response, so it seems to me
desirable to provide a way to return an error code inside the Cookie
OPT Option without disturbing the top level RCODE error field.

An error is traditional for some "security" enhancements to DNS. See,
for example, the error fields in TKEY and TSIG.

The big argument against a Cookie error field, that I can see, is that
it isn't there in the BIND implementation and running code speaks
loudly in the IETF.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Evan Hunt <[email-masked]>
Date: Mon, 30 Mar 2015 03:04:43 +0000

> it isn't there in the BIND implementation and running code speaks

When this is standardized, BIND will be changing the OPT code anyway;
modifying the option format wouldn't be a huge problem. (I suspect it'll
be more of an annoyance to change the name from "SIT" to "COOKIE".)

Would it be reasonable to leave space in the option for error reporting,
but leave it up to the implementor to decide whether to bother doing so?

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 30 Mar 2015 14:24:24 +1100

> but leave it up to the implementor to decide whether to bother doing so?

Whether you generate the error code or not is immaterial.  If it
is there then the client has to code for it.

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Tony Finch <[email-masked]>
Date: Mon, 30 Mar 2015 08:55:33 +0100

In the security considerations, it says:

1. Work Factor - To make brute force inversion hard, a cryptographic hash should be computationally expensive, especially for a general purpose processor. But FNV is designed to be very inexpensive on a general-purpose processor. (See Appendix A.)

As I understand it, the inversion resistance of crypto hash functions is not based on the computational cost of the function. A lot of effort is put in to making hashes fast, because they affect the performance of encrypted communication.

AFAIK the term "work factor" is usually a synonym for the iteration count in higher-level functions like PBKDFs which want slowing down as computers get faster.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 30 Mar 2015 16:16:50 -0400

Hi Tony,

On Mon, Mar 30, 2015 at 3:55 AM, Tony Finch <[email-masked]> wrote:
>    1. Work Factor - To make brute force inversion hard, a cryptographic
>       hash should be computationally expensive, especially for a general
>       purpose processor. But FNV is designed to be very inexpensive on a
>       general-purpose processor. (See Appendix A.)

OK. The text above is not very precise.

> As I understand it, the inversion resistance of crypto hash functions is not
> based on the computational cost of the function. A lot of effort is put in
> to making hashes fast, because they affect the performance of encrypted
> communication.

There are various ways to attack a hash function. One brute force way,
if you know the output, is to try inputs until you find one that
produces that output. Of course, a hash function is not literally
invertible since, in most cases, there are an infinite number of
inputs that will produce each possible output. But there are usually
other constraints on the "input" you are looking for, so, if it is
cheap enough to compute the hash function, and given the ability to
obtain vast computing resources through elastic cloud services or
botnets, this can still be a viable attack.

> AFAIK the term "work factor" is usually a synonym for the iteration count in
> higher-level functions like PBKDFs which want slowing down as computers get
> faster.

I do not agree. "work factor" is just what it says, amount of work. An
iteration count is one way to increase the work factor but I do not
consider them synonymous.

Thanks,
Donald