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

Mukund Sivaraman <muks@mukund.org> Fri, 31 May 2019 17:55 UTC

Return-Path: <muks@mukund.org>
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 2E1A61200F5 for <dnsop@ietfa.amsl.com>; Fri, 31 May 2019 10:55:51 -0700 (PDT)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mukund.org
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 4EdHQt5lBsx4 for <dnsop@ietfa.amsl.com>; Fri, 31 May 2019 10:55:48 -0700 (PDT)
Received: from mail.akira.org (mail.akira.org [88.198.135.228]) (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 61D2C1202ED for <dnsop@ietf.org>; Fri, 31 May 2019 10:55:48 -0700 (PDT)
Received: from jurassic.lan.banu.com (unknown [27.5.135.23]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.akira.org (Postfix) with ESMTPSA id E23AB790058C; Fri, 31 May 2019 17:55:44 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mukund.org; s=mail; t=1559325346; bh=IZQ9k4LYTpDZzWJpq9Ze9FmVrBixSfmunX2GHBE+02Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Ouv+ehuMhZkAyoisfqxDWfkWrg2CTeTC/Vd0oI+5CE/NsCS0FY/yAbvMcFJNC+gco KUFgA6hdXSfFl/AIz67B3PcP55cyEyns7Jd6k8GM1TpU3ywK3agCh9i9T9PSQehejL SJTqcTcOCGfKKcGmuG+BM/Sq65jpoolJdixfVbn4=
Date: Fri, 31 May 2019 23:24:42 +0530
From: Mukund Sivaraman <muks@mukund.org>
To: Willem Toorop <willem@nlnetlabs.nl>
Cc: dnsop@ietf.org
Message-ID: <20190531175442.GA24961@jurassic.lan.banu.com>
References: <155232074470.23098.423370236233432374.idtracker@ietfa.amsl.com> <5ea56c94-5462-ac44-462f-0f0e0a435e5e@nlnetlabs.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <5ea56c94-5462-ac44-462f-0f0e0a435e5e@nlnetlabs.nl>
User-Agent: Mutt/1.11.3 (2019-02-01)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/jTFSnJMmHcOCCxySrgK_9n1lClw>
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: Fri, 31 May 2019 17:55:51 -0000

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?

* 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).

  (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.

  (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.

* 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.

* 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).

		Mukund