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