Hi, Stephen Farrell <[email protected]>:
#Not quite sure, but I think we might get some benefit at the #moment from considering how specific fields in real protocols #undermine privacy (e.g. as Christian's draft does with the #Received header fields in mail messages) even if/when TLS or #other existing security mechanisms are properly used. My concern is that many traffic analytic approaches tend to be exceedingly robust to "protocol improvements." Protocol tweaks may accomplish little when it comes to practically improving privacy if the underlying protocol's architecture and operational practice goes unchanged. For example, when it comes to email, shouldn't section 6 of http://huitema.net/papers/draft-huitema-perpass-analthreat-00.txt basically say, "if you want to avoid traffic analytic approaches in the case of email, deploy and use Mixmaster anonymous remailers"? ( https://en.wikipedia.org/wiki/Anonymous_remailers#Untraceable_remailers ) And if we *are* talking about that sort of approach, then I think inevitably we also need to talk about how we simultaneously manage to allow *wanted* private traffic while simultaneously preventing or managing *unwanted traffic* (e.g., spam). An awful lot of current anti-spam technology depends upon either reputation (which is obviously not present in the case of anonymous/non-attributable traffic), or content analysis (which is also obviously problematic, at least if we presume use of end-to-end encryption (at least until the content is decrypted on the end-user's device)). I also think that if you're serious about email privacy, you really can't keep the discussion just at the level of sanitizing headers. You need to get into the format of the content that's allowed as well. For example, it's well known that non-plain text email content (e.g., HTML-formatted email) is potentially a serious threat to privacy due to potential use of things like tracking gifs included in HTML-formatted email. Regards, Joe _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
