Hi Stephen,

On Wed, Jan 20, 2016 at 7:10 AM, Stephen Farrell
<stephen.farr...@cs.tcd.ie> wrote:
> Stephen Farrell has entered the following ballot position for
> draft-ietf-dnsop-cookies-09: No Objection
>
> ...
>
> ----------------------------------------------------------------------
> 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.

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.

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

See below.

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

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.

> - 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?

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
 d3e...@gmail.com

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to