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

[Willem Toorop <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>