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

[神明達哉 <[e-mail]>]

At Wed, 6 May 2015 18:33:24 +0000,
Evan Hunt <[e-mail]> wrote:

> > 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.
>
> "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.

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