Subject: Re: [ietf-privacy] Media without censorship - attend IETF 85 side meeting ?

From: Vincent Roca <[email-masked]>
Date: Wed, 7 Nov 2012 02:58:04 +0100

Hello,

I've read your I-D (extremely interesting) and have a few comments:

1- The attacker model of the 20sec and kill-switch scenarios

We assume "the adversary cannot compromise smartphones or other
participating devices".
It looks rather strange to me. Personally I'd rather state the opposite:
the threat model must be that of a powerful attacker (as in the 3rd scenario).
Indeed, a device owners can be arrested and obliged to unlock its
device... He may also be obliged to move around and to collect more
information on others, using a modified device.

Is it motivated by the desire to have some progression in the threat model
in the document? If that's the case, then I understand, but state it clearly.

2- The 20sec scenario and the list of peers

Is it recommended to have such a list with possibly thousands
peers in this scenario when a device might be compromised
(previous comment)? Is it the reason why the threat model makes
the opposite assumption?

3- The 20sec scenario: clarification

I understand the wired Internet is here, and usable, even if
many links/servers/services are compromized. Am I correct?
Because if it's not the case, then how would it be possible to
broadcast a message to 20 million devices in 20sec using
bluetooth and wifi networks only? 20 millions is a lot and having
a meshed network large enough to reach them all using small
range wireless techniques seems rather challenging ;-)

4- AThe friend-to-friend scenario

What does the following bullet mean?
 o  The adversary can choose the data written to the microblogging
      layer by higher protocol layers.

(I confess I didn't read [BRIAR] where it's certainly explained)

5- Concerning Tor...

I agree, it's not the panacea for this use-case. In addition to
what you're saying, we can add that it can make the situation
worse. My colleagues have a paper on this topic:
S. Leblond, A. Chaabane, P. Manils, M.A. Kaafar, C. Castelluccia, A. Legout, W. Dabbous,
"One Bad Apple Spoils the Bunch: Exploiting P2P Applications to Trace and Profile Tor Users",
USENIX Workshop on Large Scale Exploits and Emergent Threats (LEET'11), April 2011.
http://arxiv.org/abs/1103.1518

I'll be at the side-meeting.

Cheers,

     Vincent

---

From: Rodolphe Marques <[email-masked]>
Date: Wed, 7 Nov 2012 18:59:29 +0000

Hi,

First of all I enjoyed reading the I-D and I think it is a great initiative.

I strongly agree with the point you make in section 6 with the lack of 
coordination and fragmentation of different p2p applications. What we 
see today are mostly single purpose p2p networks that can only be used 
for the application that they were designed to run.

In my opinion the way that the different scenarios are described makes 
them look like standalone issues with their own requirements and their 
own adversary models, which if tackled separately would produce the same 
fragmentation that you are trying to avoid.
The different adversary models also introduce some confusion. For 
instance in the kill-switch scenario can't the attacker also be a 
participant subscribed to Alice news feed? And in the friend-to-friend 
scenario it says Alice is placing herself in danger just by running the 
app in her smartphone, so we need some way to hide the application 
running in the smartphone. But once the message is posted in her account 
on twitter the adversary would know that it was her who wrote it and for 
it to reach twitter is because she is using some kind of electronic tool 
to make that happen.

Also the scenarios are quite similar with the only difference being the 
communication medium used (internet, ad-hoc, ...)
So I think that the document should focus on the description of a p2p 
overlay network that is private by design under a unified adversary 
model, that can be bootstrapped without the need of centralized server, 
that can run over different communication medium, and that facilitates 
the deployment of services that would make the described scenarios 
possible.

Best Regards,
     Rodolphe Marques

On 10/25/2012 06:31 PM, Johan Pouwelse wrote:
> Dear All,
> Anyone interested in attending a side meeting, to be organised in
> Atlanta (IETF 85)?
>
> Topic:   privacy enhancing technology, focused on smartphones and microblogging
> Title:    "Media without censorship"
> Date:    19:30 Thursday, November 8, 2012 (tentative, pending room
> availability etc)
> Goal:    seek feedback, measure level of interest and see if a future
> BoF is realistic
>
> The IETF Journal has just published a 2-page description of this
> initiative: http://www.internetsociety.org/articles/moving-toward-censorship-free-internet
>
> 18-page writeup of motivation, overview&scenarios:
> https://datatracker.ietf.org/doc/draft-pouwelse-censorfree-scenarios/?include_text=1
>
> There was a prior Bar BoF on this topic held last August in Vancouver.
> We had some press attention, like:
> http://translate.google.com/translate?sl=auto&tl=en&u=http%3A%2F%2Fwww.heise.de%2Fnewsticker%2Fmeldung%2FIETF-diskutiert-Netz-Standards-gegen-Zensur-1660244.html
> Martin Stiemerling was even quotes there as saying this was "Very
> interesting" and very "constructive" :-)
>
> Numerous groups work on this topic, little interaction exists,
> documentation and common terminology is lacking.
> If people are interested I would like to briefly demo the work of
> others and our own running code in this proposed gathering.
>
> Given the luxurious staffing of my university research team we now
> have running code of several building blocks for privacy enhancement.
> This allows discussion about desired architecture and approaches based
> on real-world prototyping experience. On Android market for IETF 85:
>    - Transfer a video file between two Android phones, *without* the
> receiver having any special app installed.
>      Uses NFC initiation of data transfer and Bluetooth handover
> (enabled by default on V4.1 Android).
>      (scenario 3 building block:
> http://tools.ietf.org/html/draft-pouwelse-censorfree-scenarios-02#section-4.3)
>    - Live streaming with an Android app, stream phone camera feed to
> other phones using IETF PPSP WG draft peer protocol, uses no central
> server, pure P2P
>      (scenario 1 building block:
> http://tools.ietf.org/html/draft-pouwelse-censorfree-scenarios-02#section-4.1)
>    - Record a video on a smartphone and includes one-click playable URL
> in a Twitter.com message, without requirement of any central server
>      Record a video from app, create hash check, seed content from
> phone  (PPSP compliant on-demand streaming)
>      (scenario 1 building block)
>    - Plus we now have M2Crypto experience on Android
>
> Below are the meeting notes from the Last Aug Vancouver meet.
>
> Looking forward to any feedback you might have on this or even
> attending this suggested meeting.
>
> Greetings from Holland, Johan.
>
> ######## side meeting notes by Johan Pouwelse ########
> Participants present at bar BoF: 25+
> People indicating willingness to participate, but had agenda conflicts: 5+
>
> Overall there was a lively discussion going on for over an hour. The
> diverse audience represented a wide range of backgrounds and
> expertise. From security to networking, students to professors and
> area director to decades-long IETF participants.
>
> Numerous attendants had read the initial discussion I-D document.
> Numerous questions and lack of clarity was ventilated. First,
> essential need for improvement is making the implied threat models
> explicit. It was unclear what the capability are of the adversaries.
> The context and model of information transport was not clear.
> A discussion emerged about the security of the physical layer. Nothing
> can be accomplished if trust is absent even in the physical layer. A
> common understanding was that news is created in a region without
> freedom and then needs to travel to the outside world. No term was
> defined during the discussion, for clarity, we will refer to this
> simplistically as the freedom/non-freedom border. Different transport
> protocols, dynamics and different solutions are needed on the two
> sides of this border.
>
> A second item was that the use cases (scenarios) need to be more
> clearly defined. Specifying exactly what problem is to be solved.
> Third, it was unclear why existing technology was not sufficient to
> meet the described demands. The example proposed was the tor onion
> network in combination with XMPP or the orbot smartphone app. After
> much discussion the conclusion was that existing technologies, such as
> tor facilitate protected point-to-point communication. However,
> possible desired use cases focus more on current Twitter-like social
> media practices, best typified as a "global conversation".
> Furthermore, current social media revolves around video-rich,
> real-time interaction with groups, hashtag-based discovery and social
> networking. All of these aspects are not offered or are incompatible
> with current-generation of privacy enhancing technology. A discussion
> emerged on reputation models in news reporting and information flows.
> In the current microblogging age, does the number of real-person
> followers be seen as your reputation. The question publicly posed was
> roughly: do several news sources of moderate reputation which report
> the same news story yield together a different reputation score
>
> At this point in the discussion, a summary was given (Lucy?)
> introducing the "transmorf" principle. The identities used in Twitter
> are highly identifiable labels, with a certain trust level. This hard
> identity with millions of followers is a stark contrasts with
> anonymity. It was concluded that lacking in current anti-censorship
> technology is the ability to first have stealth encrypted transport of
> news, cross the freedom/non-freedom border and then transmorf this
> news into a public accessible form with a highly identifiable label.
> This relates closely to 2nd stage verification of news.
> Discussion arose around the lack of motivation for the smartphone app
> focus in the scenario I-D. The requirements and solution space need to
> be separated.
> It was noted that the strong point of the IETF lies in describing
> architectures and protocols.
> Finally, a first stab needs to be done at defining various components.
> What are the major chunks of functionality that need to be addressed.
> Supporting area director Martin Stiemerling asked who would be willing
> to help write documents. Several people responded. Next step was
> forming a mailinglist. Given the nature of this problem, it was
> discussed if either EITF or IRTF where appropriate for this activity.
>
> Four documents to move forward:
> Use cases and threat model
> System components, definitions and system architecture
> Current technology and gap
> Detailed system design and protocol specification
>
> Scenario: no control points, everything is capture proof.
>
> ########Notes by Ronald In 't Velt#######
>
> Q: why isn't TOR + XMPP sufficient for what you want?
>
> Q (R. Bush): What is the threat model?
>
> Martin: ultimately, personal judgement
>
> Kevin Fall: intermixing problems and solutions
>
> use cases
>
> Kevin Fall: responded because DTN was mentioned
>
> ?: multiple distribution modalities
>
> separate into 2 problems: 1. transport 2. content
>
> send out anonymously, identified as highly reliable and redistributed
>
> KF: dynamic provenance
>
> distributed reputation systems
>
> multiple not-that-reliable sources adding up
>
> Martin: too big for IETF? IRTF group?
>
> scenarios, threat model, architecture, gap analysis
>
> Lucy: related work going on in W3C
> _______________________________________________
> ietf-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-privacy