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

Yoav Nir <> Thu, 10 December 2015 11:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8A3001ACF54; Thu, 10 Dec 2015 03:53:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aYG5Lfxi9q6h; Thu, 10 Dec 2015 03:53:29 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 837781ACF57; Thu, 10 Dec 2015 03:53:28 -0800 (PST)
Received: by with SMTP id v187so29153061wmv.1; Thu, 10 Dec 2015 03:53:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8w933FNAcB8LyJuXhIYig0QX8a2/DMZwCtFEmUXWv8E=; b=F8Gduvpc5J5IkNKep7sMGLdypkGVqm1eiq0Sv6rodpdL7ZKBisYvR4v1gwqRf8im7v CDEzGmjZA7zNFGs8rM07XPlZPoZxcUHVLNBJ0ipddsTpugTI1N22fGZ5f/DA758D4eqI UgMgo0VKJBY2i7NcX82edZ0nOIHSW5Y9le9miSgD3V/jcnDf02ai3kJROc8ccSS1++Op NcASm9z6P+O7GYEEt3N2wKBpnZI93nerQWJGF4mwA17SXMtf0VR58MQ8tt8v0NIpJaG1 QwIpAE4YZhAoZE6mIK/wb9INjxZMv7jxY2WSnj3dJ9ElR95n5xfhqj/hhL9Bu5fLE9Wf S9FQ==
X-Received: by with SMTP id t63mr40175186wme.40.1449748407098; Thu, 10 Dec 2015 03:53:27 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id t194sm492733wmt.11.2015. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 10 Dec 2015 03:53:26 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Thu, 10 Dec 2015 13:53:23 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Donald Eastlake <>
X-Mailer: Apple Mail (2.3112)
Archived-At: <>
Cc:, The IESG <>, secdir <>
Subject: Re: [secdir] SecDir Review of draft-ietf-dnsop-cookies-07
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 Dec 2015 11:53:31 -0000

> On 9 Dec 2015, at 4:05 AM, Donald Eastlake <> wrote:
> Hi Yoav,
> Thanks for the review. See below
> On Tue, Dec 8, 2015 at 1:52 AM, Yoav Nir <> 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.
>> 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.
> Also cache poisoning attacks due to forged responses.
>> 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.

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

>> I think it should be mentioned that the cookie mechanism is
>> notstateless. 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: and
>> 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.
> 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.

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