Subject: [DNSOP] Stephen Farrell's No Objection on draft-ietf-dnsop-cookies-09: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 20 Jan 2016 04:10:39 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-dnsop-cookies-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-cookies/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- section 3: I think it'd have been good to mention the work
being done in dprive as another future protection that should be
compatible with DNS cookies.

- I agree with Alissa's comment (2)

- section 9: I think you should note that (particularly
cleartext) client cookies allow correlation of client requests
for the duration of the client cookie lifetime, which may affect
other things the client does to try to avoid correlation and
that the set of lifetimes of all of those kinds of thing are
really interdependent.  So e.g. if a client changes it's source
IP for privacy reasons, that may be defeated if the same client
cookie is still being used for DNS requests.

- Thanks for handling the secdir review. That seems to have
ended up [1] with client cookie values that are quite similar
when only one bit of the server IP varies. Yet, [FNV] says that
it has "high dispersion." I don't know FNV well enough to know
if what Yoav called the "disturbingly similar" values in [1]
might allow for guessing cookie values if one has ever seen a
cookie value or not, but I'd be interested in chatting about
that. (In a non-blocking sense:-) In general, I'd prefer if you
recommended HMAC-SHA256 rather than FNV myself - why isn't that
really a better thing to put in the appendices? (Yeah,
performance, I know, but is the delta between FNV and
HMAC-SHA256 really so significant these days, compared to the
time it takes to lookup the DNS data itself?) 

   [1]
https://www.ietf.org/mail-archive/web/secdir/current/msg06268.html

- Can't an access point/router that was once on path but is no
longer abuse the client cookie (that it once saw go by) when
that client is still using the same value later to talk to the
same server via another n/w path?  Is that worth a mention in
the security considerations? What'd be the effect? I wondered
why you didn't include e.g. the client IP in the input in
Appendix A.1 to avoid this issue?

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 20 Jan 2016 10:20:35 -0500

Hi Stephen,

On Wed, Jan 20, 2016 at 7:10 AM, Stephen Farrell
<[email-masked]> wrote:
> ...

Section 3 is intended to talk about existing standardized DNS security
facilities. So I think it might be better in Section 9. How about:

"Work is underway in the IETF DPRIVE working grop to provide
confidentiality for DNS requests and responses which would be
compatible with DNS cookies."

> - I agree with Alissa's comment (2)

See response there.

> cookie is still being used for DNS requests.

See below.

> https://www.ietf.org/mail-archive/web/secdir/current/msg06268.html

The draft has been changed in version -09 to reverse the order of the
inputs to FNV and include a statement that the older order is weaker.
Indeed, in the earlier draft an attacker with a similar IP address
(differs in only a few low order bits) to their target could send some
requests to the server and, based on the Server Cookie the attacker
got back for themselves and the bits that differ between the
attacker's and target's IP addresses could probably guess the target's
Server Cookie with relatively few tries. However, with the reversed
order of inputs, the changes will cascade and I believe this problem
is eliminated.

The Client Cookie calculation occurs in the client, which might be
feeble. The lookup of the DNS data itself occurs in the server, which
is likely to be more powerful.

> Appendix A.1 to avoid this issue?

We really didn't think about the client changing its IP address. Seems
like some clients will very rarely change their IP address while
others might change fairly often for privacy or mobile roaming
reasons. I have no problem adding the client IP to the inputs to the
Client Cookie. Since the client is the only thing that needs to
recognize its own cookies, any existing implementations will continue
to work and will not be affected by a changed recommendation for
calculating Client Cookies.

The possibility of using the Client Cookie for tracking is also a good
point that should be mentioned in the Security Considerations.

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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 20 Jan 2016 22:52:22 +0000

Hi Don,

> compatible with DNS cookies."

Lovely.

> order of inputs, the changes will cascade and I believe this problem

Ah, good thanks.

> is likely to be more powerful.

Sure, but nonetheless the overall hash cpu consumption is not,
I would think, the most interesting place to optimise. I do
get that FNV has folks who argue for it too though.

> calculating Client Cookies.

Grand.

> point that should be mentioned in the Security Considerations.

Great. The issue that concerns me is e.g. that I change my IPv6
address daily at noon and my DNS cookie daily at midnight and
end up getting no benefit from either. If you could mention that
or similar that'd be great, but if you'd rather not, I do agree
that there's a more general "overlapping temporary identifiers
re-identification threat" document that could be written that'd
generalise from the this kind of thing. (If someone here wants to
write that, I'd AD-sponsor any sensible text on the topic;-)

Cheers,
S.