Skip to main content

Last Call Review of draft-ietf-dnsop-cookies-07
review-ietf-dnsop-cookies-07-secdir-lc-nir-2015-12-10-00

Request Review of draft-ietf-dnsop-cookies
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-12-14
Requested 2015-12-03
Authors Donald E. Eastlake 3rd , Mark P. Andrews
Draft last updated 2015-12-10
Completed reviews Genart Last Call review of -07 by Peter E. Yee (diff)
Genart Telechat review of -09 by Peter E. Yee (diff)
Secdir Last Call review of -07 by Yoav Nir (diff)
Secdir Telechat review of -08 by Yoav Nir (diff)
Opsdir Last Call review of -07 by Dan Romascanu (diff)
Assignment Reviewer Yoav Nir
State Completed Snapshot
Review review-ietf-dnsop-cookies-07-secdir-lc-nir-2015-12-10
Reviewed revision 07 (document currently at 10)
Result Has Issues
Completed 2015-12-10
review-ietf-dnsop-cookies-07-secdir-lc-nir-2015-12-10-00
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.