search

core-wg / echo-request-tag

Other
0 stars 0 forks source link

Privacy considerations of Echo as Cookie #41

Closed chrysn closed 5 years ago

chrysn commented 5 years ago

While not designed for that, the Echo option can be abused as mechanism like HTTP's Cookie (especially when preemptive Echo values are passed around), and I'm pretty sure we don't want that.

We should at least point that out somewhere, and say that servers MUST NOT abuse it (however to phrase that -- "use Echo to correlate requests for other purposes than showing frechness and reachability"?).

For actual mitigation, we could recommend (or even demand?) that clients only send preemptive Echo values on the same endpoint (5-tuple) on which they were received -- so that if their address changes, no Echo value will leak identity.

chrysn commented 5 years ago

To still allow Echo in OSCORE groupcom (new server asks for Echo, client repeats it in next multicast, others ignore it), we could limit that mitigation to unauthenticated use cases (as the client has a known persistable identity with OSCORE anyway).

emanjon commented 5 years ago

Yes, this should definitely be a privacy consideration.

emanjon commented 5 years ago

I wrote some initial text for the privacy consideration regarding this. Please revieew, modify and add things.

Should we have any considerations for group OSCORE? of should we let draft-dijk-core-groupcomm-bis and group OSCORE discuss that. Echo Request is hopefully published before them.

gselander commented 5 years ago

I think John refers to this commit: bcceb8a

chrysn commented 5 years ago

I'm almost happy with it, the last word I'm unhappy with is being addressed in an upcoming commit that closes it by drawing on a solution to the "the spec does not say anything regarding taking echo from (no-security, DTLS, [...]) and using it in (no-security, DTLS, [...])" comment,