Hiya, On 10/28/2013 05:49 PM, Joe St Sauver wrote: > 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
Not all changes need be tweaks. Some might be though. > 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, To be honest, I don't see how we can "fix" mail myself so that its not vulnerable to pervasive monitoring. I think we can make such monitoring somewhat harder via better use of TLS, and that's worth doing, but beyond that, I don't see much that can be done without changes that I don't think are likely to happen. I'd be delighted to be proven wrong on that, so I'm happy to see it discussed but I'm not hopeful. Meanwhile, there are plenty of other protocols that are also worth a look and might be more easily improved in this respect, so even if mail isn't tractable, other things may well be. S. > 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 > > _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
