Hi Dean,
On Feb 11, 2013, at 1:10 PM, Dean Willis wrote:
>
> There's also a second aspect of "identifiability" relating to "traffic
> analysis" that I think may not be well-developed, and perhaps there's a
> better term for the concept. Can a given packet or flow of packets
> intercepted by an intermediary be examined to tell the intermediary what kind
> of traffic is present, or even what protocol is being used?
Agreed that there is more to be said about this. I suggest the following update
to the definition of traffic analysis:
OLD:
$ Traffic Analysis: The inference of information from observation
of traffic flows (presence, absence, amount, direction, and
frequency). See [RFC4949].
NEW:
$ Traffic Analysis: The inference of information from observation
of traffic flows (presence, absence, amount, direction, timing, packet
size, packet composition, and/or
frequency), even if flows are encrypted. See [RFC4949].
I also suggest adding this as a second paragraph in 4.1.1:
Surveillance can impact privacy even if the individuals being surveilled are
not identifiable or if their communications are encrypted. For example, an
observer or eavesdropper that conducts traffic analysis may be able to
determine what type of traffic is present (real-time communications or bulk
file transfers, for example) or which protocols are in use even if the observed
communications are encrypted or the communicants are unidentifiable. Protocols
that use predictable packet sizes or timing or include fixed tokens at
predictable offsets within a packet can facilitate this kind of surveillance,
which can adversely affect the individuals involved (for example, by having
some of their communications blocked or redirected).
Note that there is also some discussion of this in section 5.3.
> One might consider this as part of "traffic analysis", but it might be useful
> to give specific guidance beyond "use TOR."
>
> For example, does the protocol used a fixed token at a fixed offset within
> the packet (such as a protocol number) to indicate the protocol of the
> packet? Does it use constant data packet sizes and timing that indicate a
> real-time flow as opposed to a file transfer? One might consider this
> "unlink ability at the packet level", but I suspect it's subtly different
> from the primary usage of unlink ability.
>
> Another undeveloped concept is how does the protocol in question contribute
> to the privacy of other protocols simply by being used. For example, if we
> have lots of different protocols that have similar entropy levels and lack
> distinguishing marks, it's harder for an intermediary to guess which type a
> particular packet is. We're also missing the concept of entropy (for which
> "more" is generally "better", from a privacy perspective) from the whole
> discussion.
>
So the question is: what do we want to recommend to protocol developers? We
could express a preference for randomized packet sizes, token locations, and
inter-packet timing, but it seems like we would need some discussion of how to
judge when such measures are appropriate (given that gazillions of existing
protocols are in wide use and don't do those things). Also, we would need to
address the complexity that this introduces into implementation logic. And what
sort of workable recommendations are there for how developers can harmonize
their own protocols' entropy levels with all of the other protocols out there?
I agree that these are good goals, but in this doc we're trying to be as
concrete as possible about how your average IETFer should be designing
protocols.
Alissa
>
>
_______________________________________________
ietf-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-privacy
