Subject: [DNSOP] Feedback: draft-eastlake-dnsext-cookies

From: John Kristoff <[email-masked]>
Date: Tue, 2 Dec 2014 14:34:36 -0600

I remember a much older version of this mechanism, but I imagine many
are not.  It isn't until quite a bit into the document where the reader
is really given any idea about what DNS cookies are or how they work.
This might be annoying to the reader, because especially in section two
that describes various threats, there are numerous statements about how
DNS cookies might help mitigate these threats.  I'd suggest a succinct
summary of what DNS cookies are or do, more than "they are a
"transaction security mechanism" in the introduction.

Section 2.1.2,, second to last sentence reads in part:

  ""The computational or communications burden caused by such requests
  may not dependent on a forged IP source address [...]"

In the first part, I think there is a missing verb "be" between "not"
and "dependent".

Section 2.1.2, last sentence reads in part:

  "Use of DNS cookies should enables a server to reject forged queries
  from an off path attack with relative ease and before [...] "

Remove the word "should".  I'd also recommend removing phrase "with
relative ease and ", since that is largely superfluous and subjective.

Something to consider mentioning in section 3 is TCP-AO.  I don't think
it has ever been widely deployed outside of BGP services, but TCP-AO
(IETF RFC 5925) is an option and might be perhaps worth mentioning that
is is, but only for TCP and has not seen deployment in the DNS, even on
a limited basis where TSIG has often been used for things like
AXFR/IXFR between slaves and masters.

The ASCII cookie option figures 1 and 2 look a little awkward with that
2 byte hole following the error code.  Maybe it would be better to draw
it as 16-bit aligned as IETF RFC 6891 does?

The statements at the end of sections 4.1 and 4.2 conclude similarly:

  "A client MUST NOT use the same Client Cookie value for queries to
  all servers."

  "A server MUST NOT use the same Server Cookie value for responses to
  all clients."

The obvious logical question would be, but it is OK to use the same
cookie for "some" of them?

The nomenclature of BADCOOKIE is misleading since a missing server
cookie for an initial request is in no way "bad", but perfectly
legitimate.  This is minor, but it might be syntactically preferable to
use better descriptors.

Lastly, a couple of random thoughts... should cookies received be
available to logging systems or collected by passive DNS systems for
analysis and debugging?

As implicitly described in 5.2.3, there is a risk of making a DDoS
attack a little worse when cookies are implemented.  If cookies become
widely deployed, servers might want to return a TC=1 response if there
is a cookie OPT but no server cookie present for that bootstrapping
query.

John