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

From: Mukund Sivaraman <[email-masked]>
Date: Fri, 31 May 2019 23:24:42 +0530

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

---

From: Loganaden Velvindron <[email-masked]>
Date: Fri, 31 May 2019 22:09:29 +0400

On Tue, Mar 12, 2019 at 3:29 PM Willem Toorop <[email-masked]> wrote:

> DNS Cookies are currently impractical in such deployments, because one
> implementation - even though it shares its secret with another
> implementation - cannot validate the Server Cookies constructed by that
> other implementation, because their methods for constructing Server
> Cookies differ.
>
> This draft provides precise directions for creating Server Cookies to
> align the implementations.  In doing so, this draft introduces a
> registry for functions suitable for Cookie construction.  More
> specifically, FNV and HMAC-SHA-256-64 are obsoleted and SipHash-2.4 is
> introduced as a suitable function.
>
> Willem
>
> -------- Forwarded Message --------
> Subject: New Version Notification for
> draft-sury-toorop-dns-cookies-algorithms-00.txt
> Date: Mon, 11 Mar 2019 09:12:24 -0700
> From: [email-masked]
> To: Willem Toorop <[email-masked]>, Ondrej Sury <[email-masked]>
>
>
> A new version of I-D, draft-sury-toorop-dns-cookies-algorithms-00.txt
> has been successfully submitted by Willem Toorop and posted to the
> IETF repository.
>
> Name:           draft-sury-toorop-dns-cookies-algorithms
> Revision:       00
> Title:          Algorithms for Domain Name System (DNS) Cookies
> construction
> Document date:  2019-03-11
> Group:          Individual Submission
> Pages:          7
> URL:
>
> https://www.ietf.org/internet-drafts/draft-sury-toorop-dns-cookies-algorithms-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-sury-toorop-dns-cookies-algorithms/
> Htmlized:
> https://tools.ietf.org/html/draft-sury-toorop-dns-cookies-algorithms-00
> Htmlized:
>
> https://datatracker.ietf.org/doc/html/draft-sury-toorop-dns-cookies-algorithms
>
>
> Abstract:
>    [RFC7873] left the construction of Server Cookies to the discretion
>    of the DNS Server (implementer) which has resulted in a gallimaufry
>    of different implementations.  As a result, DNS Cookies are
>    impractical to deploy on multi-vendor anycast networks, because the
>    Server Cookie constructed by one implementation cannot be validated
>    by another.
>
>    This document provides precise directions for creating Server Cookies
>    to address this issue.  Furthermore, [FNV] is obsoleted as a suitable
>    Hash function for calculating DNS Cookies.  [SipHash-2.4] is
>    introduced as a new REQUIRED Hash function for calculating DNS
>    Cookies.
>
>    This document updates [RFC7873]
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
Small typo:
I would suggest this:
Section 4 4th paragraph:
"implement only a pseudorandom functions for DNS Cookies"
 to
"implement only a pseudorandom function for DNS Cookies"

  [SipHash-2.4] is a pseudorandom function suitable as message
   authentication code, and this document REQUIRES compliant DNS Server
   to use SipHash24 as a mandatory and default algorithm for DNS Cookies
   to ensure interoperability between the DNS Implementations.

Also, I would suggest explaining a little bit the advantages of SipHas-2.4:

fast computation + quite secure up to now.

_______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>