Re: Is traffic analysis really a target (was Re: [saag] Is opportunistic unauthenticated encryption a waste of time?)

[Michael StJohns <[e-mail]>]

At 12:32 PM 8/24/2014, Eric Burger wrote:
>I am concerned with the drive to make all traffic totally opaque. I’ll be brief: we have an existence proof of the mess that happens when we make all traffic look benign. It is called “everything over port 80.” That ‘practical’ approach drove the development of deep packet inspection, because everything running over port 80 was no longer HTTP traffic. It meant we could no longer prioritize traffic (in a good sense - *I* want to make sure my VoIP gets ahead of my Web surfing ahead of my FTP). It meant we could no longer apply enterprise policy on different applications. It drove ‘investment’ in the tools that today dominate pervasive monitoring.
>
>Good job folks for unintended consequences.


For a longer and more complete discussion on this, please see also RFC3639.  It was drafted at a time a national actor was contemplating blocking VoIP traffic at the actor's borders so it could tariff voice traffic by forcing it onto the PTT POTS system. 

There will be unintended consequences for whatever this OS thing ends up getting called.  It would be nice if we could do enough design and analysis prior to deployment to turn them into "carefully considered, more good for the user than harm to the network" consequences.

Later, Mike





>On Aug 23, 2014, at 5:33 PM, Stephen Farrell <[e-mail]> wrote:
>
>> 
>> Hiya,
>> 
>> On 23/08/14 22:05, Bernard Aboba wrote:
>>> Stephen Farrell:
>>>> However, say we're wrong and someone who thinks OS is a waste of
>>>> time is actually correct, what would such a person recommend that
>>>> we do as well as, or instead of, OS?
>>> 
>>> [BA] It depends on who we are trying to protect, and from what (or
>>> whom). 
>> 
>> Sure.
>> 
>>> If the target is protection of dissidents from oppressive
>>> regimes, then you need something much more comprehensive than
>>> 'unauthenticated opportunistic encryption" (e.g. along the lines of
>>> Tor). 
>> 
>> Right. That's a hard target and involves far more than crypto,
>> whether OS or not.
>> 
>> One thing clearly involved there is that traffic analysis is
>> a threat, and I'd fully accept that we should be thinking about
>> ways in which we could make our protocols better against that
>> in general, even if we're not tackling the specific problems of
>> dissidents. For example, if my toilet emits packets with every
>> flush, encryption of any sort isn't going to disguise that so
>> traffic analysis will also be relevant for the Internet-of-Toilets.
>> 
>>> If the target is protection against PM within wealthy nations,
>>> then you'd need something that can't be rendered harmless by a modest
>>> budget increase. A number of MITM protection mechanisms have been
>>> suggested (e.g. DANE, channel binding, etc.). 
>> 
>> But isn't that what the IETF and security folks within the
>> IETF have been aiming for for a couple of decades? I mean aiming
>> for an end-state where we have mutual-auth more-or-less everywhere.
>> I don't consider that we've succeeded wildly to be honest;-)
>> 
>> What should we be doing differently is really my question.
>> 
>>> Also, in this category
>>> should be mechanisms for protecting privacy against private-sector
>>> adversaries. As long as private companies can amass huge dociers
>>> without resort to PM (or without the need to subvert OS), and are
>>> willing to sell that personal information to third parties (dodgy
>>> ones, let alone governments),  one wonders whether government
>>> agencies would make better use of their funds by "buying"
>>> surveillance, rather than trying to "build" it.
>> 
>> As it happens we had some discussion about e2e email security in
>> Toronto. Current plan is to start a new mailing list for that - a
>> bunch of us are chatting about how to scope that so we're less
>> likely to mess up. (More on that next week I hope.)
>> 
>> Now email is of course just one application (though a cornerstone
>> application). Which other applications/mechanisms should we be
>> considering that'd help here? FWIW, I'm very open to us trying to
>> help anywhere we could credibly do that. (Credibility requiring
>> that stuff be technically doable, be something that should be done
>> in the IETF and have enough warm bodies interested in doing work.)
>> 
>> Cheers,
>> S.
>> 
>> PS: If you or someone has a specific suggestion for a thing on
>> which we should be working, then maybe these lists are too broad
>> for detailed discussion of that. In such cases, the [e-mail]
>> list is probably a good place to triage whether a topic is one we
>> should try pursue in the IETF.
>> 
>
>
>