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
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
