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

Yoav Nir <ynir.ietf@gmail.com> Tue, 08 December 2015 06:53 UTC

Return-Path: <ynir.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 6F6E71B33E8; Mon, 7 Dec 2015 22:53:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 0id5zdz1fCkf; Mon, 7 Dec 2015 22:53:00 -0800 (PST)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 873601B33E6; Mon, 7 Dec 2015 22:52:57 -0800 (PST)
Received: by wmww144 with SMTP id w144so17086445wmw.0; Mon, 07 Dec 2015 22:52:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=ltYMtvLRaA+rtFCnPOXTW5wJlEipBXJahc29wbQ4DYo=; b=w2tnl5hYurCw+Rz6h2Io87g3kEGTnobpkijvDF6BlpMQN0wSSryC2JJU7SKYRZgs3j s2PMRPaV6CQITzq0ReX56DIUIrbrFwVnuS+kOiCYdQwY30+zQ4ch7IBB3eMX8BZ7JJ0+ NTV9zv8MmqChD+hkWoR6xMG7mrKvpBFJvTQwm4+1jx8rVUeF5pftAT6tIyoreGidkcsh IHiLxQ9vdiu2msbgFRdVRc07EMG+OYsGH/COsoQ7Aii9zxLB+BTTa1h64vlcdqJ7MX/l UI1vc+erTlIyBLj73eALCwFQqYeCz6NvXWuJEPE16tJ6WoAr0cRwr08BKBqdnn9COvc3 iUbw==
X-Received: by with SMTP id v7mr1212015wja.25.1449557576078; Mon, 07 Dec 2015 22:52:56 -0800 (PST)
Received: from yoavs-mbp.mshome.net ([]) by smtp.gmail.com with ESMTPSA id a76sm19932203wma.19.2015. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 07 Dec 2015 22:52:55 -0800 (PST)
From: Yoav Nir <ynir.ietf@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <6FAFF2EB-0865-43B7-AAC9-2071B6297D16@gmail.com>
Date: Tue, 8 Dec 2015 08:52:52 +0200
To: secdir <secdir@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-dnsop-cookies.all@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
X-Mailer: Apple Mail (2.3096.5)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/saSO2LIwqKe0lMgwOrn4fg_Tky8>
Subject: [secdir] SecDir Review of draft-ietf-dnsop-cookies-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Dec 2015 06:53:02 -0000


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.


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.


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