Subject: [secdir] SecDir Review of draft-ietf-dnsop-cookies-07

From: Yoav Nir <[email-masked]>
Date: Tue, 8 Dec 2015 08:52:52 +0200

Hi.

I have reviewed this document as part of the Security Directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the Security Area Directors.  Document authors, document editors, and WG chairs should treat these comments just as they would any other IETF Last Call comments.

Version reviewed: draft-ietf-dnsop-cookies-07

Summary: has issues.

The draft describes a cookie mechanism (a little more complex than SYN cookies or IKEv2 cookies) to prevent DoS, specifically amplification attacks on the DNS, where an off-path attacker sends requests with spoofed source to a DNS server, causing a lot of DNS traffic towards the spoofed source.

ISSUES:

Section 5.5 describes what happens when a server rolls over its secret. If the server receives a server cookie fitting the previous server secret, it MUST reply with the new, correct, server cookie. This is implied, but IMO should be stated explicitly, because it is temptingly efficient to just copy the server cookie if it's valid (and a cookie matching the previous secret is considered valid for a while) into the response rather than re-calculating the server cookie before sending.

An attacker could bypass the whole mechanism by not including the OPT, and the way to deal with this is rate limiting on the server for clients without valid cookies. I think this should be said explicitly in the Security Considerations section.

Section 9.1 suggests as a cookie algorithm "HMAC-SHA256-64 [RFC6234]", which I take to be SHA-256 truncated to 64 bits. There is no such function (not any other truncation) in RFC 6234. Even shortened hashes that do exist in other documents, such as SHA512-256 are not simple truncations but also change the initialization vectors for the original hash function, although shortened HMACs such as those used in IPSec *are* simple truncations.

Same section, it is not clear what the criteria are for selecting an algorithm. Specifically, I don't know what makes FNV strong enough whereas something else (CRC?) is not. I don't think there's a practical issue with FNV, but it would be better to state the goals.

NITS:

"To bypass the weak protection provided by using TCP requires, among other things, that an off-path attacker guessing the 32-bit TCP sequence number in use."
s/guessing/guess/  or s/that an off-path attacker guessing/an off-path attacker to guess/

The word "weak" is mentioned 18 times, in addition to related terms such as "limited protection". The mechanism does what it does. Sure it does not include 521-bit elliptic curve cryptography, but I don't think this needs to be mentioned so often.

I think it should be mentioned that the cookie mechanism is stateless. Of course all of DNS is stateless, but it should be mentioned that the mechanism requires no per-client state on the *server*, but does require per-server state on the *client*.

Section A.1: As mentioned above, I don't know the requirements for an algorithm. But just looking at the following example, I don't like the construction. So I set the secret to 0x3132333435363738, and considered two IP addresses: 97.98.99.100 and 97.98.99.101. Running both through FNV, I get the following:
     FNV64("12345678abcd") = 0xb7fd1aee15822b05
     FNV64("12345678abce") = 0xb7fd1aee15822b04
     
On the other hand, if we reverse the order of secret and IP address, we get:
	FNV64("abcd12345678") = 0x6c1e749e200cc845
	FNV64("abce12345678") = 0x5d17f5e450f9a52c
	
It seems like the FNV function is more sensitive to changes in earlier bytes than to changes in later bytes. So placing the IP address first makes this look more like a hash function. This is not a cryptographic argument, but I believe it should be better to put the IP address first.

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 8 Dec 2015 21:05:50 -0500

Hi Yoav,

Thanks for the review. See below

On Tue, Dec 8, 2015 at 1:52 AM, Yoav Nir <[email-masked]> wrote:
>
> Hi.
>
> I have reviewed this document as part of the Security Directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> Security Area Directors.  Document authors, document editors, and WG
> chairs should treat these comments just as they would any other IETF
> Last Call comments.
>
> The draft describes a cookie mechanism (a little more complex than
> SYN cookies or IKEv2 cookies) to prevent DoS, specifically
> amplification attacks on the DNS, where an off-path attacker sends
> requests with spoofed source to a DNS server, causing a lot of DNS
> traffic towards the spoofed source.

Also cache poisoning attacks due to forged responses.

> ISSUES:
>
> Section 5.5 describes what happens when a server rolls over its
> secret. If the server receives a server cookie fitting the previous
> server secret, it MUST reply with the new, correct, server
> cookie. This is implied, but IMO should be stated explicitly,
> because it is temptingly efficient to just copy the server cookie if
> it's valid (and a cookie matching the previous secret is considered
> valid for a while) into the response rather than re-calculating the
> server cookie before sending.

OK. Note that it is likely that many servers will always send a new
Server Cookie with a new time stamp in response to every request,
similar to the example in Appendix B.2 which is implemented in a beta
release of BIND.

How about adding something like "When a server responds to a request
containing a old Server Cookie that the server is treating as correct,
the server MUST include a new Server Cookie in its response."

> An attacker could bypass the whole mechanism by not including the
> OPT, and the way to deal with this is rate limiting on the server
> for clients without valid cookies. I think this should be said
> explicitly in the Security Considerations section.

How about adding the following: "An attacker that does not know the
Server Cookie could do a variety of things, such as omitting the
COOKIE OPT option or sending a random Server Cookie. In general, DNS
servers need to take other measures, including rate limiting
responses, to protect from abuse in such cases. See further
information in Section 5.2."

> Section 9.1 suggests as a cookie algorithm "HMAC-SHA256-64
> [RFC6234]", which I take to be SHA-256 truncated to 64 bits. There
> is no such function (not any other truncation) in RFC 6234. Even
> shortened hashes that do exist in other documents, such as
> SHA512-256 are not simple truncations but also change the
> initialization vectors for the original hash function, although
> shortened HMACs such as those used in IPSec *are* simple
> truncations.

OK. How about "HMAC-SHA256-64 [RFC6234]" -> "HMAC-SHA256 [RFC6234]
truncated to 64 bits", which is what was meant.

> Same section, it is not clear what the criteria are for selecting an
> algorithm. Specifically, I don't know what makes FNV strong enough
> whereas something else (CRC?) is not. I don't think there's a
> practical issue with FNV, but it would be better to state the goals.

What criteria would you recommend? The only mandatory requirement is
in the last sentences of Sections 4.1 and 4.2. FNV64 is intended to be
the definition of the recommended algorithm strength in the current
draft.

> NITS:
>
> "To bypass the weak protection provided by using TCP requires, among
> other things, that an off-path attacker guessing the 32-bit TCP
> sequence number in use."  s/guessing/guess/ or s/that an off-path
> attacker guessing/an off-path attacker to guess/

OK.

> The word "weak" is mentioned 18 times, in addition to related terms
> such as "limited protection". The mechanism does what it does. Sure
> it does not include 521-bit elliptic curve cryptography, but I don't
> think this needs to be mentioned so often.

Hey, we didn't want anyone to think we were claiming cryptographically
strong protection. If you like, we can pick some of the less prominent
uses of "weak" and eliminate them.

> I think it should be mentioned that the cookie mechanism is
> stateless. Of course all of DNS is stateless, but it should be
> mentioned that the mechanism requires no per-client state on the
> *server*, but does require per-server state on the *client*.

Well, the recommended implementation method is stateless at the server
but it could be implemented in a stateful manner. For example, the
server could generate a random quantity as the Server Cookie for each
{ client IP and Client Cookie } and remember it. That would, in some
ways, make the Server Cookie strength as strong as possible,
reminiscent of a one-time pad. But I don't think anyone will ever do
that.

How about adding to Section 4.2: "When implemented as recommended, the
server need not maintain any cookie related per client state."

> Section A.1: As mentioned above, I don't know the requirements for
> an algorithm. But just looking at the following example, I don't
> like the construction. So I set the secret to 0x3132333435363738,
> and considered two IP addresses: 97.98.99.100 and
> 97.98.99.101. Running both through FNV, I get the following:
> It seems like the FNV function is more sensitive to changes in
> earlier bytes than to changes in later bytes. So placing the IP
> address first makes this look more like a hash function. This is not
> a cryptographic argument, but I believe it should be better to put
> the IP address first.

You are using FNV-1 while the recommended version of FNV in
draft-eastlake-fnv is FNV-1a. Here are the results with FNV-1a:

     FNV64-1a("12345678abcd") = 0x5a8c6219760802e5
     FNV64-1a("12345678abce") = 0x5a8c611976080132

I would agree that putting the IP address first is stronger but it is
more expensive computationally. With the secret first you can
pre-compute FNV64(secret) and then use that as the FNV offset when
calculating the cookie from the IP address (or IP address and Client
Cookie in the case of the server). However, the savings are small,
particularly for IPv6 and/or at the server where the Client Cookie is
also included, so I would be OK with reversing the order.

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

---

From: Yoav Nir <[email-masked]>
Date: Thu, 10 Dec 2015 13:53:23 +0200

> On 9 Dec 2015, at 4:05 AM, Donald Eastlake <[email-masked]> wrote:
> 
> Hi Yoav,
> 
> the server MUST include a new Server Cookie in its response.”

LGTM

> information in Section 5.2.”

Agree

> truncated to 64 bits", which is what was meant.

Good

> uses of "weak" and eliminate them.

It’s only style, than substance, but I think mentioning the weakness in Abstract, Introduction and Security Considerations is enough.

>> notstateless. Of course all of DNS is stateless, but it should be
> server need not maintain any cookie related per client state.”

LGTM

> also included, so I would be OK with reversing the order.

Even with 1a the “hashes” look disturbingly similar. But the justification makes sense and I don’t see any security issue.

Thanks!

Yoav