Subject: [DNSOP] Seeking discussion of draft-ietf-dnsop-cookies-01

From: Evan Hunt <[email-masked]>
Date: Fri, 1 May 2015 23:21:30 +0000

Greetings,

The current DNS Cookies document (draft-ietf-dnsop-cookies-01) has two
similar but distinct protocols described in it: the DNS Cookie option as
designed by Donald Eastlake, and the Simple DNS Cookie option designed by
Mark Andrews and experimentally implemented (under the name Server Identity
Token, or SIT) in BIND 9.10.

The chief difference between the two is the presence of an error code field
in Eastlake cookies; Andrews found it redundant/unnecessary (as discussed
in https://www.ietf.org/mail-archive/web/dnsop/current/msg13984.html).
The hope was that including both mechanisms in the draft would lead to
a working group discussion about whether the error code is, in fact,
necessary or desirable; unfortunately, not much discussion has happened
yet.

I would very much like to see this protocol nailed down enough that
we can request a code point and start including this feature in BIND
without the #ifdef's around it.  I'm hoping for WGLC in the Prague
timeframe.  May I request that people weigh in on the error code
issue?

Speaking for myself, I agree with Mark: the benefits of including error
codes in the option are slim and other mechanisms such as FORMERR work
just as well in almost every scenario, so it doesn't justify the cost in
additional complexity.

Thanks,

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: "Wessels, Duane" <[email-masked]>
Date: Fri, 1 May 2015 23:51:49 +0000

> On May 1, 2015, at 4:21 PM, Evan Hunt <[email-masked]> wrote:
> 

I'm inclined to agree.  I was a bit torn because there have been so many other
times I wished a certain feature had additional error signaling, but I found it
hard to justify the complexity in this case.

DW

---

From: Shane Kerr <[email-masked]>
Date: Sun, 3 May 2015 09:47:50 +0200

Evan,

On Friday, 2015-05-01 23:21:30 +0000,
Evan Hunt <[email-masked]> wrote:
> Speaking for myself, I agree with Mark: the benefits of including
> error codes in the option are slim and other mechanisms such as
> FORMERR work just as well in almost every scenario, so it doesn't
> justify the cost in additional complexity.

This makes sense to me. Best to tackle a single issue at a time.

Although perhaps a next logical step would be to think about improving
the error code situation in general. :)

Cheers,

--
Shane

---

From: 神明達哉 <[email-masked]>
Date: Wed, 6 May 2015 11:19:07 -0700

At Fri, 1 May 2015 23:21:30 +0000,

> necessary or desirable; unfortunately, not much discussion has happened

Can someone explain why we'd need the separate error codes based on
the position of supporting them (i.e, not to persuade others on
dropping them)?  msg13984.html was basically written to argue against
them, so it could potentially and unintentionally be biased.  I'll try
to find any such explanation myself, but if someone already knows it
better can do that, it would also help.

--
JINMEI, Tatuya

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 6 May 2015 14:32:11 -0400

It appeared from me from the meeting in Dallas and the sparse list 
discussion is while the error codes would seem "interesting/useful", 
there is no good use case to show usefulness, which is my Mr. Andrews 
did not implement them.

I was approaching this (and as we approach the idea of WGLC) that we 
drop the error codes for the time being since there is no working 
implementation; and there is no strong desire for them.

I would rather lean in this direction, remove the error codes, and send 
the draft into WGLC as "Experimental".   Does the working group have any 
strong opinions on this position?

tim

On 5/6/15 2:19 PM, 神明達哉 wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Evan Hunt <[email-masked]>
Date: Wed, 6 May 2015 18:33:24 +0000

> better can do that, it would also help.

"Next by thread" from msg13984 has Donald explaining his position,
though not in great detail. If I understand him correctly, he wants to
enable a server to include cookie errors even if it's chosen in this
case to return an otherwise normal NOERROR response to the client.

---

From: 神明達哉 <[email-masked]>
Date: Thu, 7 May 2015 09:11:53 -0700

At Wed, 6 May 2015 18:33:24 +0000,

> case to return an otherwise normal NOERROR response to the client.

Okay, so it seems to be a case where the YAGNI principle can apply.

On the other hand, on reading the draft and
https://www.ietf.org/mail-archive/web/dnsop/current/msg13984.html
more closely, I can see some not-so-trivial difference.  Assume DNS
cookies are deployed sufficiently and some operators start refusing
queries without cookies.  Then an attacker that wants to spoof a
victim client (probably for an amplification attack) would send
queries with an invalid server cookie anyway.  According to Section
7.2.4.1 of draft-ietf-dnsop-cookies-01, the server will still return
the full size of response, so the attack will still be effective.  On
the other hand, a server implementation with the separate error code
field can choose to send a minimal response with a valid server cookie
according to Section 5.2.3 of the draft, thereby minimizing the risk
of allowing amplification attacks while still allowing legitimate
clients to bootstrap or re-synchronize.

In the following part of msg13984.html:

>> For (b) retrying should succeed.  That said tc=1 would also be just as
>> effective at triggering a retry.

perhaps Mark tried to say we could achieve the same effect if the
server returns a minimal size of response with TC bit on and with the
correct server cookie.  If it was his intent, it's true to some
extent.  But these two approaches are not entirely the same since
using the TC bit has a side effect of forcing the use of TCP.

So the choice does not seem to be a no-brainer to me.  But, in the
end, I wouldn't be opposed to the idea of removing the separate error
code field.  The above difference wouldn't be so substantial anyway,
and wouldn't justify the introduction of a generic error code field.

One last point I'd like to make is that, assuming the above
understanding of mine is correct, I'd suggest including the TC bit
hack in the initial protocol description.  Since it has a side effect
it's better to have it sooner so we can update the spec if early
deployments suggest the need for it.

--
JINMEI, Tatuya

---

From: Evan Hunt <[email-masked]>
Date: Thu, 7 May 2015 17:14:21 +0000

On Thu, May 07, 2015 at 09:11:53AM -0700, 神明達哉 wrote:
> According to Section 7.2.4.1 of draft-ietf-dnsop-cookies-01, the server
> will still return the full size of response, so the attack will still be
> effective.

Subject to rate limiting restraints, yes.  BIND's experimental SIT
implementation exempts clients from rate limiting if they have a valid
cookie, but not otherwise.  The cookie is more of a way for legitimate
client traffic to be privileged, than for attack traffic to be mitigated;
we have other mechanisms in place to handle mitigation.

That said, however, I like the idea of adding the TC=1 response to the
protocol specification as a MAY.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 08 May 2015 12:24:07 +1000

In message <[email-masked]>
> using the TC bit has a side effect of forcing the use of TCP.

Which gets the client/server what is needed for this and future
transaction.  It avoids the two denial of service senarios below.

Just sending back BADCOOKIE leads to a potential denial of service
with misconfigured anycast servers with differing shared secrets /
server cookie algorithms.

Just sending back NEEDCOOKIE leads to a potential denial of service
when DNS COOKIE is not understood.

Additionally a server can choose to send a minimal response rather
than a full response or TC=1.  In both cases it is a unverified
query source and should be handled like all unverified query sources.

I also have a hard time envisioning a client that supports DNS
COOKIES not sending a DNS COOKIE by the time one could reliably
send back NEEDCOOKIE and have it reliably acted on.  The only reason
for not sending a DNS COOKIE in the first place would be to handle
broken EDNS servers and that is a solvable problem if everyone that
depend on the DNS for their pay cheque does their bit to fix it.

At the moment sending back NEEDCOOKIE would be equivalent to REFUSED
and I don't see the equivalence changing.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]