Re: [secdir] SecDir Review of draft-ietf-dnsop-cookies-07
Yoav Nir <ynir.ietf@gmail.com> Thu, 10 December 2015 11: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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3001ACF54; Thu, 10 Dec 2015 03:53:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYG5Lfxi9q6h; Thu, 10 Dec 2015 03:53:29 -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 837781ACF57; Thu, 10 Dec 2015 03:53:28 -0800 (PST)
Received: by mail-wm0-x230.google.com with SMTP id v187so29153061wmv.1; Thu, 10 Dec 2015 03:53:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.28.170.66 with SMTP id t63mr40175186wme.40.1449748407098; Thu, 10 Dec 2015 03:53:27 -0800 (PST)
Received: from [172.24.251.92] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id t194sm492733wmt.11.2015.12.10.03.53.25 (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 <ynir.ietf@gmail.com>
In-Reply-To: <CAF4+nEGG5Q1mWHO=4iXFTF-MHwtEuw796TTAt3pVTF7gnnMsnQ@mail.gmail.com>
Date: Thu, 10 Dec 2015 13:53:23 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <79E9B127-7738-4E18-8731-0A467B4BA0CC@gmail.com>
References: <6FAFF2EB-0865-43B7-AAC9-2071B6297D16@gmail.com> <CAF4+nEGG5Q1mWHO=4iXFTF-MHwtEuw796TTAt3pVTF7gnnMsnQ@mail.gmail.com>
To: Donald Eastlake <d3e3e3@gmail.com>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/gjQVzvNAuApVEtHgmoZMJC5strY>
Cc: draft-ietf-dnsop-cookies.all@ietf.org, The IESG <iesg@ietf.org>, secdir <secdir@ietf.org>
Subject: Re: [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: Thu, 10 Dec 2015 11:53:31 -0000
> On 9 Dec 2015, at 4:05 AM, Donald Eastlake <d3e3e3@gmail.com> wrote: > > Hi Yoav, > > Thanks for the review. See below > > On Tue, Dec 8, 2015 at 1:52 AM, Yoav Nir <ynir.ietf@gmail.com> 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. > >> 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.” LGTM >> 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.” Agree >> 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. Good >> 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.” LGTM >> 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. > > 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. Thanks! Yoav