Subject: [DNSOP] Review of draft-ietf-dnsop-cookies

From: Paul Hoffman <[email-masked]>
Date: Sun, 5 Jul 2015 16:48:58 -0700

Greetings. This is a WG LC review of draft-ietf-dnsop-cookies, which I had not looked at carefully in some time. In short: it looks great, the document is complete and easy-to-read, and we probably should have done this nearly a decade ago when Donald started the work.

Substantial:

In Sections 4.1 and 4.2, it says that the cookies MUST NOT be the same for all recipients. This should be SHOULD NOT, to match the SHOULDs above. If an implementation does a stupid and uses the same cookies everywhere, it is no worse off for it, it just isn't getting as much protection as expected. (If I'm wrong about that latter bit, then the reason for the MUST NOT should be given in both sections.)

Section 5.4 seems unnecessary and possibly harmful. Why have an additional means to detect support other than "ask any question, even one that is going to get a REFUSED or NXDOMAIN answer"? The new mechanism will wreak havoc on tools that are watching DNS requests, for no real reason. I propose that this section be removed, or replaced with a simply "if you want to know whether the server supports cookies, ask anything".

Editorial:

In Section 2.2, "the Dan Kaminsky attack" sounds like an attack by someone, not described by someone. The parenthetical can probably be removed, or turned into an informative reference from something that Dan wrote.

In Section 5.2, second paragraph, "as before" is unclear. This probably means "as if no COOKIE OPT option had been sent", but it should be explicit.

Procedural:

The third paragraph of Section 5.3 gives a new scenario in which TCP SHOULD be used. Thus, I think this draft updates RFC 5966, and the draft should be marked as such, even if it is only for this one important part. Also, this paragraph should refer to RFC 5966.

I continue to be concerned that draft-eastlake-fnv, which is likely to be used by implementations of cookies, is still just a draft, not an RFC. It's not for this WG to do, but anyone implementing this draft should read that draft, send comments, and let's get that published as well.

--Paul Hoffman

---

From: Mark Andrews <[email-masked]>
Date: Mon, 06 Jul 2015 11:16:00 +1000

In message <[email-masked]>, Paul Hoffman writes
:
> Greetings. This is a WG LC review of draft-ietf-dnsop-cookies, which I had no
> t looked at carefully in some time. In short: it looks great, the document is
>  complete and easy-to-read, and we probably should have done this nearly a de
> cade ago when Donald started the work.
> 
> Substantial:
> 
> In Sections 4.1 and 4.2, it says that the cookies MUST NOT be the same for al
> l recipients. This should be SHOULD NOT, to match the SHOULDs above. If an im
> plementation does a stupid and uses the same cookies everywhere, it is no wor
> se off for it, it just isn't getting as much protection as expected. (If I'm 
> wrong about that latter bit, then the reason for the MUST NOT should be given
>  in both sections.)
>
> Section 5.4 seems unnecessary and possibly harmful. Why have an additional me
> ans to detect support other than "ask any question, even one that is going to
>  get a REFUSED or NXDOMAIN answer"? The new mechanism will wreak havoc on too
> ls that are watching DNS requests, for no real reason. I propose that this se
> ction be removed, or replaced with a simply "if you want to know whether the 
> server supports cookies, ask anything".

"Wreak havoc" is a little bit over dramatic.  If the tools can't
handle QCOUNT == 0 they are already broken.  This is the Internet
and the tools should be expecting to get total garbage packets.
Not sending QCOUNT == 0 won't help them.  QCOUNT == 0 is potentially
useful for other things.  Existing nameservers mostly return FORMERR
though Google's nameservers (8.8.8.8) just drop the query despite
it being a legitimate RFC 103[45] query.  We looked to see if we
needed a Updates RFC 103[45] and as far as we can tell we don't.

As for sending a random query you then have to deal with all the
different behaviours for sending a query to a server which is not
expecting the QNAME on top of discovering if COOKIE is supported.

Additionally this is just the equivalent of syn / syn ack / ack at
the DNS/UDP level.  I'm yet to extend dig to do this but it is on
my to do list (dig +get-cookie-first (defaulting on) looks like a
good option name).  "dig +cookie" will be on by default so that
broken EDNS option behaviour by servers is made visible and it more
closely matches what recursive servers supporting COOKIE will do.

If you want to play with a dig that supports +header-only it is
available at https://source.isc.org

[rock:~/git/bind9] marka% dig +cookie +header-only +qr @8.8.8.8

; <<>> DiG 9.11.0pre-alpha <<>> +cookie +header-only +qr @8.8.8.8
; (1 server found)
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50037
;; flags: rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 28f7b8576f571ca9
;; QUESTION SECTION:

;; QUERY SIZE: 35

;; connection timed out; no servers could be reached
[rock:~/git/bind9] marka% 

[rock:~/git/bind9] marka% dig +cookie +header-only +qr @f.root-servers.net

; <<>> DiG 9.11.0pre-alpha <<>> +cookie +header-only +qr @f.root-servers.net
; (2 servers found)
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40527
;; flags: rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 5abce2514ce635b2
;; QUESTION SECTION:

;; QUERY SIZE: 35

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 40527
;; flags: qr rd; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; Query time: 407 msec
;; SERVER: 2001:500:2f::f#53(2001:500:2f::f)
;; WHEN: Mon Jul 06 10:27:28 EST 2015
;; MSG SIZE  rcvd: 23

[rock:~/git/bind9] marka% 

[rock:~/git/bind9] marka% dig +cookie +header-only +qr

; <<>> DiG 9.11.0pre-alpha <<>> +cookie +header-only +qr
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5967
;; flags: rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 64f2c6d5a5726046
;; QUESTION SECTION:

;; QUERY SIZE: 35

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5967
;; flags: qr rd; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 64f2c6d5a57260466b74174c5599cc27d6979aa9b3385ad1 (good)
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jul 06 10:30:31 EST 2015
;; MSG SIZE  rcvd: 51

[rock:~/git/bind9] marka% 

> Editorial:
> 
> In Section 2.2, "the Dan Kaminsky attack" sounds like an attack by someone, n
> ot described by someone. The parenthetical can probably be removed, or turned
>  into an informative reference from something that Dan wrote.
> 
> In Section 5.2, second paragraph, "as before" is unclear. This probably means
>  "as if no COOKIE OPT option had been sent", but it should be explicit.
> 
> Procedural:
> 
> The third paragraph of Section 5.3 gives a new scenario in which TCP SHOULD b
> e used. Thus, I think this draft updates RFC 5966, and the draft should be ma
> rked as such, even if it is only for this one important part. Also, this para
> graph should refer to RFC 5966.

RFC 5966 has "or for other operational reasons," which covers this.
Implementations have always been free to sent requests over TCP.
e.g. netstat has been using TCP rather than UDP for decades.

> I continue to be concerned that draft-eastlake-fnv, which is likely to be use
> d by implementations of cookies, is still just a draft, not an RFC. It's not 
> for this WG to do, but anyone implementing this draft should read that draft,
> send comments, and let's get that published as well.
> 
> --Paul Hoffman
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 6 Jul 2015 07:30:46 -0700

> needed a Updates RFC 103[45] and as far as we can tell we don't.

It really doesn't matter if they are "already broken" in your view: what matters is creating a protocol that doesn't unnecessarily cause damage to the DNS.

> expecting the QNAME on top of discovering if COOKIE is supported.

Why? As I described above, it is fine if the QNAME is nonsense to the server: it will still answer with the cookie.

> closely matches what recursive servers supporting COOKIE will do.

It sounds like you want this protocol to purposely cause problems for servers that are not implemented the way you want. A less brittle design would not do that.

So, I again propose that this part of the new protocol be removed because it is unnecessary and possibly harmful.

> e.g. netstat has been using TCP rather than UDP for decades.

Good catch. Ignore my request because 5966 already covers it.

--Paul Hoffman

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 6 Jul 2015 11:00:26 -0400

Hi,

I'll just reply where Mark did not:

> Greetings. This is a WG LC review of draft-ietf-dnsop-cookies, which I had not looked at carefully in some time. In short: it looks great, the document is complete and easy-to-read, and we probably…

Thanks.

> In Sections 4.1 and 4.2, it says that the cookies MUST NOT be the same for all recipients. This should be SHOULD NOT, to match the SHOULDs above. If an implementation does a stupid and uses the sam…

No. The document claims that cookies provide weak security. If exactly
the same cookie can be used for everyone, then that claim is wrong and
it provides no security, at least for servers -- anyone could query
the server using their true IP address, take the one cookie from the
reply, and replay that cookie to the server in forged IP address
queries, etc.

It would be nice to be able to say that implementations MUST provide a
different cookie for every recipient, but with 64 bit pseudorandom
functions, there will always be a residual probability of hash
collisions. But I can conceive of no reason to allow an implementation
to claim to be conforment while providing no security.

The "SHOULDs" you refer to relate to implementation suggestions. The
MUST NOT is the rock bottom minimum requirement that all
implementations have to meet.

> ...

OK.

> In Section 5.2, second paragraph, "as before" is unclear. This probably means "as if no COOKIE OPT option had been sent", but it should be explicit.

OK.

> ...

My apologies for being slow on completing the fnv draft. I have made
substantial progress on that but I'm quite busy this week and next. I
plan to post a revision during the IETF meeting week. If you want to
apply more pressure to me :-) you could suggest that the reference to
fnv from cookies be made a normative reference. After all, the draft
says you SHOULD use something at least as strong as fnv...

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Tue, 07 Jul 2015 01:02:28 +1000

In message <[email-masked]>, Paul Hoffman writes
:
> It really doesn't matter if they are "already broken" in your view: what matt
> ers is creating a protocol that doesn't unnecessarily cause damage to the DNS
> .

How can a intrinsically hop-by-hop "extension" "damage" the protocol?
It either works for the client/server pair or it doesn't just the
same as sending a NSID option either works or it doesn't or sending
a IQUERY either works or it doesn't.  This is all client driven.

"extension" because it is already permitted.

>  it will still answer with the cookie.

And it complicates the code handling the responses.

> It sounds like you want this protocol to purposely cause problems for servers
>  that are not implemented the way you want. A less brittle design would not d
> o that.

It will cause zero problems for servers.  All the issues fall on
the clients.  This is true of using new EDNS options and/or when
sending qcount == 0.  The problem is not exercising the new code
paths from the very begining.

For example no one exercised/tested EDNS version negotiation in the
wild and now everyone is afraid to go to EDNS(1).  That said I ran
a EDNS recursive server for months that sent EDNS(1) queries and
for the most part there were few issues.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 6 Jul 2015 08:42:20 -0700

> How can a intrinsically hop-by-hop "extension" "damage" the protocol?

Because there are lots of other systems that watch either end. A logger that expects a query is the one I am most concerned about, but there are probably others as well. I understand that you feel "they are broken and we shouldn't care about them". I care about avoiding broken things if we can get the same functionality.

> a IQUERY either works or it doesn't.  This is all client driven.

But watched by other system.

> And it complicates the code handling the responses.

Not at all! You fully covered (and I think correctly so) all the cases of queries that get non-zero RCODE responses still getting the server cookie.

--Paul Hoffman

---

From: Ray Bellis <[email-masked]>
Date: Mon, 06 Jul 2015 16:44:25 +0100

On 06/07/2015 16:42, Paul Hoffman wrote:

> Because there are lots of other systems that watch either end. A
> logger that expects a query is the one I am most concerned about, but
> there are probably others as well. I understand that you feel "they
> are broken and we shouldn't care about them". I care about avoiding
> broken things if we can get the same functionality.

I've personally written a logger that expects QDCOUNT == 1

However it just drops the packet if that's not true, it doesn't "break".

Ray

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 6 Jul 2015 08:47:16 -0700

> implementations have to meet.

OK, this is fair. Please consider adding "In order to maintain the security properties of this protocol," to the beginning of each of those MUST NOT sentences.

> says you SHOULD use something at least as strong as fnv...

No need for that. It's OK for this draft to point to a draft of FNV because the current draft feels good enough to implement from (but I say that not having done so!). But do keep moving on the FNV draft: it would have been useful to have this be an RFC reference, and there are lots of other places in the IETF where people won't downref to a draft.

--Paul Hoffman

---

From: Mark Andrews <[email-masked]>
Date: Tue, 07 Jul 2015 09:50:03 +1000

In message <[email-masked]>, Paul Hoffman writes
:
> Because there are lots of other systems that watch either end. A logger
> that expects a query is the one I am most concerned about, but there are
> probably others as well. I understand that you feel "they are broken and
> we shouldn't care about them". I care about avoiding broken things if we
> can get the same functionality.

qcount == 0 can be used to probe for lots of things, including but
not limited to determining if a server is up as there are servers
that fail to respond to qnames they do not serve but do respond to
qcount == 0 queries.

Just sending a COOKIE option will break some system somewhere.
Worrying too much about breaking things leaves you paralysed.  I
would have said COOKIE + EDNS(1), to get into well defined behaviour
for unknown options, but there wasn't enough benefit to doing it
at too many systems drop EDNS(1) queries rather that send back
BADVERS.  That is not to say we shouldn't do a EDNS version jump
for something else.

Adding qcount == 0 later would also be worse than doing it now as
there would be nothing tying the two changes together.

> >> Why? As I described above, it is fine if the QNAME is nonsense to the
> server:
> >> it will still answer with the cookie.
> >
> Not at all! You fully covered (and I think correctly so) all the cases of
> queries that get non-zero RCODE responses still getting the server cookie.

I covered all the cases of a well behaved servers.  There are non
well behaved servers (or firewall server combos) out there that
don't even meet RFC 1034 / RFC 1035 minimums of responding.

See the example above.