Privacy considerations of Echo as Cookie

[chrysn]

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]

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]

Yes, this should definitely be a privacy consideration.

[emanjon]

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]

I think John refers to this commit: bcceb8a

[chrysn]

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,