ietf
[Top] [All Lists]

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

2014-08-24 15:02:29
On 25/08/2014 07:06, Michael StJohns wrote:
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.  

RFC3205 (BCP56) said some of it a bit earlier, and was ignored. I'd say that
RFC3639 was ignored too. For a practical lesson on the same topic, I suggest
a critical study of all the RTCWEB drafts and of draft-ietf-dart-dscp-rtp.
I think they show the depth of the hole we are in.

   Brian

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 
<stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie> 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 
perpass(_at_)ietf(_dot_)org
list is probably a good place to triage whether a topic is one we
should try pursue in the IETF.








<Prev in Thread] Current Thread [Next in Thread>