Re: [DNSOP] Fwd: New Version Notification for draft-sury-toorop-dns-cookies-algorithms-00.txt

Willem Toorop <willem@nlnetlabs.nl> Wed, 26 June 2019 12:27 UTC

Return-Path: <willem@nlnetlabs.nl>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064071200FA for <dnsop@ietfa.amsl.com>; Wed, 26 Jun 2019 05:27:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl
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 ji7vh5q6CSCH for <dnsop@ietfa.amsl.com>; Wed, 26 Jun 2019 05:27:32 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CC3812032A for <dnsop@ietf.org>; Wed, 26 Jun 2019 05:27:31 -0700 (PDT)
Received: from [IPv6:2a04:b900:0:1:bd41:b937:46b8:a8fd] (unknown [IPv6:2a04:b900:0:1:bd41:b937:46b8:a8fd]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 0EA57174F6 for <dnsop@ietf.org>; Wed, 26 Jun 2019 14:27:28 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=pass (p=none dis=none) header.from=nlnetlabs.nl
Authentication-Results: dicht.nlnetlabs.nl; spf=pass smtp.mailfrom=willem@nlnetlabs.nl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1561552048; bh=LrqJ4NMpTc2kj9RZ0jFDW4fxrfspkUF2QM4HtefVcR0=; h=To:References:From:Subject:Date:In-Reply-To; b=Y+ukfak3T8J9CySLSfucFZKyGLzn5x9AzvJz7jeYT7FAILgwsa/ItfYat6dKJ/hWy J5jD+9iEhS9uTuiKvZ/CyrVw9WVPoTrFd54IPPMVlqIWdP76srczt5jJvjcV+6DSrz zZgxYOsRQ9tTvdbxV7xFJ53oZcSbf1OQb08/5wXE=
To: dnsop@ietf.org
References: <155232074470.23098.423370236233432374.idtracker@ietfa.amsl.com> <5ea56c94-5462-ac44-462f-0f0e0a435e5e@nlnetlabs.nl> <20190531175442.GA24961@jurassic.lan.banu.com>
From: Willem Toorop <willem@nlnetlabs.nl>
Openpgp: preference=signencrypt
Autocrypt: addr=willem@nlnetlabs.nl; prefer-encrypt=mutual; keydata= mQINBE1s81EBEACuJzGgccrmYEAzHc//vBq66gH7orM0GtKfQZHh4uR1FMxZXl07WevUYNuB ywTpinU9rpY1Q3S4w6QgNklgpsaHXmbOpyFjJ8FpllV8TRPiXiNrNxTpMnlb6InoszopX69t kBVHTP6cJkNgPx6R4BM0ARqEGQmOL8mAcoWyGVzbsamuGRaia54zs/kc3i9yiqEzRkoQmfwr 7sr49n7gOpmaqXvonOSiUvgEziep77emMcqVa/qZxR1r7KUq85qTNTqsQwl2cQdKS7WwOeuG 6ZIJmJ1bakriKzLBYF5xIHKSYJW0ZA20tNFrVKgTkEjiXvAJh4HlJEIi35tqa/IzWUJSc1ai nhBjxbwSl8BRq5aaPgwB+xXiDqY6BrQW1slvl5TF2A6Xr7JJ0rkH3EZgXxABAZ3WJ3RLwq1z 8jnNYj+UW/mSLsbOtgfOiBhFUXMZneHvVVvz6F6XAtyrejDl5sD2gnzm1VDfK6T6bvLtR7zr kWre0lpycDmgmUKgaEiXzfLvwT9RaWk8GdqU2GG+QOiwf+hT0peDieuodjMr59sUbx7GqVe/ 45rJBRSx+HCl2Jm7Th2Xr0kpStCd7ebVoEq9wpMyu+dM9wOTtibA9P3+9u4rAdimpAdQxEbh WbRNCng2EVhThbqRK3cTZLbtqKaWgAJqa/IQVpL9b5ps8Z4JVQARAQABtCNXaWxsZW0gVG9v cm9wIDx3aWxsZW1AbmxuZXRsYWJzLm5sPokCPgQTAQIAKAIbIwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AFAlbUE5oFCRDr7kkACgkQ5fj4IS93pJiGfA/8C1+/M+EaQItVzQ/iPCbagBTq WOSispMzJne9gmimJzPs+lxgnrXOuYlIBywHpWB2Jmz45h+Cc4+di48WQfV9tHENn9MVFkwK zSdcY6v5eot6xSY5FRHS226MPR9UJ8/z5PvlizZUVbbM+Ngxg3Rx045Q0FnQm0o5VasEJ1Po R3CSiELJoZ13ukTk5pQlKyVknUKH1E1ds+Xtg1jpZBqiLiBzcLkKWYqBvrXI6XAEPr+woRgj 3xV8P24Uj232uK7xoe82jWIeZWXt/AbHBSmNOWPIgMd9i3FjdeTDml5sZSy3BlDYMr8hINen hYLhdLpJnXwPcsaj0ivcV+xSjLtSh0mE4gudcVhk5XR1M6emSlATC6+Bqn0M9JNTn4SHhkNS yo87aPwKqWFDlvjAZlRyPym9miJBlzech2uOlYSk6GFuead7MpGAipf5PwNNRKDMDi3y+H47 YG2izbrqj3cOZdqZmErwrzCU8xVkxzY/EY6w/MNMFNeqmXVGxzIZ8y9KAjH6JO96M/AxS4mX HJh1ocfHtSm90Ahy/HPJK+2+5+IgkAymKsvyIbvjs7FccMUo+OiSPWYi+xO/NXA4pBlUuGmV 55Kog7ym1flzo8OD9uHfLPrVORBHgnsITbzf9vgJ0emy8fxMCkzFT334gC1OVhD1ff1frbPX yVbcGI8AO+q5Ag0ETWzzUQEQAKTs4hWz94K66PtsHj/cBtHmJCJx9BsHP8eoUjd4iBR7cWgT Tgt1PGCNBzCPGIuUia808dqxu1L8OWjQpwXDCjXqAibn0mCJMRONVszxJKkjYnZGKGOo8cg7 OmQBZyEd6qrfxVf/dwHLsdQTJZzz9bGOxuYVAAu0q3PHW5gGFc+pp3eN47qzGMxEjsoETj/c laxjqisohG13/hkP6PvDoD7OOdOGdQQP8b4GRBD6rZ/FqMLv4C80zDnzCH1rLpNGQplf1any 06WTAsDL4f6gEALH62TIxOX4U7WxeuvHxyKXOAuN+ex/MvF2az124YbcWC7t1dqVW3ys20zK aememyXSKxV6aMn4KBcJF3CdM1oABZDyviL9el7Q/yQylpZC6El4QowaPIOAuzOdIc6cuM6P TWvBArcKVgQhWfJshfeFmfkxpz/hWc9K40yCjmb+hPZIr3RbXSsQItUUkBqOSMHNroIgX+Ia WMq3e7yMHdMqlKr0lU52lfBbfECjleB/NO4K3SGJBPzTgLtze+LsWxSJQoQMWKv6ISwQrW3r smUjqgQNrSGROX3rRy8Nvuzravs4a3FmdUpHIWw2KfY2M6AsX9HBFuRsimgqFjQm5VbqXA7N tHJCnA1RvqXlg/iJ5w+DElHosxwjHS+UbejDGmVQ+ITqlh3991osPjZq1Iy1ABEBAAGJAiUE GAECAA8CGwwFAlbUE5oFCRDr7kkACgkQ5fj4IS93pJjBwxAAnko5CSFDX/ZqW97satNacACH SAOOM8/jz1p2QtJSwbrbLsJRMpN1mSnjXWPBTmXoP4SGHGtxTVZxrYCpSMEHMqOV4yK3QlUn QXnf+CSvo2Ud3rpCh/lFLVHqG2Sy5Ietf/T+GGsoPd9DIdTHO0aFlW2yRQPxSrbYpv1v2aAC gRO4114qkex2j36diqlLod/OU4OQ51nuSesjTrUM9Fz6ikBJ1UDjakjAXe/HiRxUmdv4LANC mso+Gn17Co5lUdpn3fa8zTwNNAgLm6RBiBSSdaYExM9ir6pHrcWL5N+iZKnVmfE5CBufziZq 7V1E3I4FRuvDN4echbf58c6YxBQDsd9VZMJeFWY60w4JEXpHQdt129GS1FN/2PQ8NmAUXYCk YYk6Lv1tnGJCSLnD3ObLyWm+sjA5yAK2H8WU+nutsDF63yFJujNMpmB3bi9+699TzsyQNVKd 2fH38cgk1gZFb6Nbx9+lrTIwzAJJlOu8UwbR0HgGuRmrWp0EIm3tcy4xqWF3CavnM22BAOKK KH+qnwx8BRrx58coHQFMswW4W7Bo+jpKbQJ4RV2cXUEbmHbYUoXDHZyv/RzOI46dXAoWFc3o CoqLqpsZYZstJ4UJHXB5aHi1zxJDwzKxsflmSKfIUr3glRWCy/ylcPMEXzPBb3qbGFMUboio UjqLuNV4SSY=
Message-ID: <67d0bbe6-f6c9-d0d8-7039-1f55b9944f09@nlnetlabs.nl>
Date: Wed, 26 Jun 2019 14:27:21 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1
MIME-Version: 1.0
In-Reply-To: <20190531175442.GA24961@jurassic.lan.banu.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/idfVfmc81FqUVMrSw9qDL7_c28g>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-sury-toorop-dns-cookies-algorithms-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jun 2019 12:27:35 -0000

Thanks Mukund,

Comments inline below...

On 31-05-19 19:54, Mukund Sivaraman wrote:
> On Tue, Mar 12, 2019 at 12:29:13PM +0100, Willem Toorop wrote:
>> Dear DNSOP,
>>
>> A new draft has been submitted addressing the issue of DNS Cookies in
>> multi-vendor anycast deployments.
> 
> I came across this draft today in a thread on the dns-operations@ list.
> 
> Here is a short review:
> 
> * Any draft that specifies things clearly / clarifies things is
>   welcome. The following criticizes some things that stand out.
> 
> * The method in section 3 looks different from the syntax BIND currently
>   uses for the server cookie. Is this going to break (server-side)
>   compatibility with existing deployed versions of BIND that are in
>   various products when used as part of a cluster?

Yes.  Unfortunately there is no version indicator in current BIND's
implementation and therefore it is impossible to detect whether a cookie
is generated by BIND previous mechanism or not.  We do need the version
field in the server cookie to signal how the cookies are constructed and
how they can be verified.

Implementations can choose to fallback to previous BIND behaviour or
have that behaviour set explicitly in a configuration...


> * I feel HMAC-SHA256 should not be moved to "MUST NOT", because:
> 
>   (a) This proposal leaves SipHash as the only choice. AES is proposed
>   as "MAY" and from the commentary in section 4, it appears the draft
>   considers AES as obsolete for DNS COOKIE. It is not as straighforward
>   as a HMAC for non-cryptographers anyway (typical DNS programmers)
No Mukund, we had an inter-operable DNS Server cookies implementation
based on SipHash in the hackathon of IETF 104 in Prague for BIND, Knot,
NSD, Unbound and PowerDNS recursor.  So no implementation barriers.

>   (b) HMAC-SHA256 is already available as a subroutine in typical DNS
>   implementations because of its use in other parts of DNS such as TSIG.
>   On the contrary, SipHash would typically be a new dependency for DNS
>   implementations unless they're already using it for something such as
>   hashtables. Due to its youth, many projects appear to "roll their own"
>   SipHash in C code which may not be far off in performance
>   vs. libcrypto's SHA-256.

SipHash is now included in OpenSSL. Also the reference implementation is
in the Public Domain with a very permissive license: (see
https://github.com/veorq/SipHash/blob/master/LICENSE )

>   (c) While SHA-256 is slower than SipHash, it should still be OK to
>   have it as an option for the server cookie part, especially as some
>   modern processors include specialized instructions for computing
>   SHA-256 as part of their ISA. It is a server admin's decision about
>   the performance tradeoff. On my machine, result of a quick benchmark
>   of SHA-256 for single core appears fine for typical usage.

To get an inter-operable version of DNS Cookies out in implementations
quickly, I think we should restrict ourselves to SipHash now.  We, the
OS dns software vendors) have proven that we can do such an
implementation based on SipHash-2.4 quickly during the IETF105 hackathon.

Additional methods with different pseudorandom functions can be
discussed and added later on.

> * For compatibility, the AES method should be specified in more detail
>   than "other implementations MAY implement AES algorithm as implemented
>   in BIND" as otherwise it has the same problem this draft is attempting
>   to address.

Agree, I have just submitted a new version of the draft, which I will
forward to the list after this reply.

> 
> * DNS COOKIE primarily addresses two problems - cache poisoning at the
>   client side, and amplification attacks on the server side.
> 
>   There have been multiple complaints (even previously from the current
>   thread on dns-operations@) on multi-implementation DNS clusters having
>   issues with getting the server cookie / secret right.
> 
>   By discarding FNV (which is not a PRF) this new draft makes frequent
>   updating of keys unnecessary which is a welcome relief, esp. when the
>   key has to be synchronized across multiple machines.
>   
>   However, there is still the possibility that two implementations don't
>   get it right somehow, due to incompatibility of methods or
>   implementation bugs.
> 
>   I feel it would be beneficial to introduce a mode (as mandatory to
>   implement) where the server can be confgured to simply echo the option
>   back to the client. It would then replicate a client-supplied nonce in
>   the query message (technically the client-cookie part as far as the
>   protocol client is concerned), and would serve at least one out of the
>   two main purposes of DNS COOKIE - addressing cache poisoning. This
>   would be trivial to implement without burdening smaller DNS projects,
>   have almost zero per-query computation overhead (even SipHash is more
>   costly than FNV), and work reliably as far as DNS clusters are
>   concerned without getting keys and algorithm details right.
> 
>   It would be possible to say "at least you can echo the option" to an
>   implementor who complains about not implementing COOKIE due to
>   complexity or performance or some other reason. Having COOKIE
>   universally implemented would mean that we can remove the dependence
>   on source port randomization which is quite expensive and also
>   difficult to get right (e.g., from behind NAT, and also due to
>   deficiencies in randomizing the order of source port choice properly).

I like your observation! Such randomization would also be fragmentation
attack resistant (because it is at the end of the DNS message).

I have not heard implementers complaining about complexity yet though.
SipHash-2.4 cookies are easy to implement (see the successful results
from the hackathon) and also have these properties.

-- Willem
> 
> 		Mukund
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>