idnits 2.17.1 draft-pouwelse-censorfree-scenarios-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2012) is 4166 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'YOUTH' is mentioned on line 701, but not defined == Missing Reference: 'FORCEDLOGIN' is mentioned on line 704, but not defined == Missing Reference: 'OPENMICRO' is mentioned on line 717, but not defined == Missing Reference: 'DATING' is mentioned on line 720, but not defined == Missing Reference: 'TREND' is mentioned on line 724, but not defined == Missing Reference: 'BOOTSTRAP' is mentioned on line 727, but not defined == Missing Reference: 'BUBBLE' is mentioned on line 751, but not defined == Missing Reference: 'BRIAR' is mentioned on line 748, but not defined == Missing Reference: 'NKOREA' is mentioned on line 708, but not defined == Missing Reference: 'ZEROKNOW' is mentioned on line 730, but not defined == Missing Reference: 'EGYPTSTUDY' is mentioned on line 713, but not defined == Missing Reference: 'TOR' is mentioned on line 742, but not defined == Missing Reference: 'CAPLIMIT' is mentioned on line 734, but not defined == Missing Reference: 'LEVELS' is mentioned on line 737, but not defined == Missing Reference: 'DIASPORA' is mentioned on line 745, but not defined == Missing Reference: 'TWIMIGHT' is mentioned on line 754, but not defined == Missing Reference: 'MUSUBI' is mentioned on line 758, but not defined == Missing Reference: 'TRIBLER' is mentioned on line 762, but not defined == Missing Reference: 'REBELLIONTV' is mentioned on line 765, but not defined == Missing Reference: 'DISPERSY' is mentioned on line 768, but not defined == Missing Reference: 'LIBSWIFT' is mentioned on line 772, but not defined Summary: 0 errors (**), 0 flaws (~~), 24 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Pouwelse, Ed. 3 Internet-Draft Delft University of Technology 4 Intended status: Standards Track October 22, 2012 5 Expires: April 25, 2013 7 Media without censorship (CensorFree) scenarios 8 draft-pouwelse-censorfree-scenarios-02 10 Abstract 12 This document describes some scenarios in which one can imagine that 13 the ability of authoritarian regime to censor news dissemination is 14 reduced. It tries to draw some conclusions about what's desirable 15 and what's not acceptable for users in those scenarios. 17 The CensorFree objective is to standardize the protocols for 18 microblogging on smartphones with a focus on security and censorship 19 resistance. Microblog entries are short text messages, possibly 20 enriched with pictures or streaming video. The goal is to devise 21 protocols which guard against all known forms of censorship such as: 22 cyberspace sabotage, digital eavesdropping, infiltration, fraud, 23 Internet kill switches and lawyer-based attacks with the best known 24 protective methods. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 25, 2013. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Goal: microblogging . . . . . . . . . . . . . . . . . . . . . 4 63 4. Driving scenarios . . . . . . . . . . . . . . . . . . . . . . 5 64 4.1. 20sec scenario . . . . . . . . . . . . . . . . . . . . . . 6 65 4.1.1. Adversary model: A simplistic attacker . . . . . . . . 6 66 4.1.2. Scenario details and architectural requirements . . . 6 67 4.2. Kill-switch scenario . . . . . . . . . . . . . . . . . . . 8 68 4.2.1. Adversary model: An advanced attacker . . . . . . . . 8 69 4.2.2. Scenario details and architectural requirements . . . 8 70 4.3. friend-to-friend scenario . . . . . . . . . . . . . . . . 9 71 4.3.1. Adversary model: A powerful attacker . . . . . . . . . 9 72 4.3.2. Scenario details and architectural requirements . . . 10 73 4.4. Transmorph ability . . . . . . . . . . . . . . . . . . . . 10 74 4.5. A single global conversation . . . . . . . . . . . . . . . 11 75 4.6. Spammers and hoaxes . . . . . . . . . . . . . . . . . . . 11 76 5. Design principles: simplicity and prior success . . . . . . . 12 77 6. Background rant: lack of coordination and fragmentation . . . 12 78 7. Current running code and related work . . . . . . . . . . . . 13 79 8. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 8.1. Use cases and threat model . . . . . . . . . . . . . . . . 15 81 8.2. System components, definitions and system architecture . . 15 82 8.3. Current technology and gap . . . . . . . . . . . . . . . . 15 83 8.4. Detailed system design and protocol specification . . . . 15 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 85 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 88 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 89 11.3. URL References . . . . . . . . . . . . . . . . . . . . . . 15 91 1. Requirements Language 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [RFC2119]. 97 2. Introduction 99 Bits moving across the Internet are vulnerable to surveillance and 100 censorship on an unprecedented scale. Today, both Internet providers 101 and governments possess the ability to monitor the moves of their 102 digital citizens from central infrastructure points. This monitor 103 ability creates significant potential for abuse, and a threat that 104 goes beyond the scope of mere monitoring or filtering. 106 Governments have demonstrated their ability to disable communications 107 networks in times of crisis. During the 2011 Arab Spring, Egyptian 108 authorities demanded that telecommunication companies sever their 109 broadband connections and mobile networks--both local and European 110 operators were forced to comply, and, as a result, digital Egypt 111 vanished. Despite the country's decentralized infrastructure, an 112 Internet blackout was relatively easy to carry out. The roles and 113 consequences of social media (e.g., Facebook and Twitter) during that 114 same period further illustrate the capacity governments have for 115 Internet censorship and the challenges activists face in combating 116 it. The April 6 Youth Movement from Egypt committed digital dissent 117 in full public view. According to The New York Times[YOUTH], the 118 movement "provided a structure for a new generation of Egyptians, who 119 aren't part of the nation's small coterie of activists and opinion 120 makers, to assemble virtually and communicate freely about their 121 grievances." But moving protest organizations to social media 122 accessible to the public-at-large can hold surprising risks. On the 123 ground, the movement's organization of labor strikes and protests in 124 Facebook groups, many with thousands of followers, triggered arrest 125 and imprisonment. Protesters in other countries quickly took note of 126 Egypt's lesson and disabled their public Facebook profiles. In 127 response, one government initiated social media searches on incoming, 128 young, plane travelers by forcing them to login to Facebook upon 129 arrival, thereby revealing online activities and any anti-government 130 sympathies.[FORCEDLOGIN] 132 A glimmer of hope exists. The Arab Spring shows that a new 133 generation is claiming their right to express themselves. 134 Microblogging, social media in general and traditional satellite news 135 broadcast networks are perceived as critical catalysts for political 136 change. Generic computational fabric is soon getting in the hands of 137 two billion people with the growth of smartphones and increasingly 138 affordable communication. These smartphones are increasingly used to 139 record and spread disruptive audiovisual material, even in regions 140 without media freedom. 142 Democratic countries also face a dilemma. Restrictions on the free 143 information flow is the topics of several proposed laws by elected 144 representatives. The strength of copyright law impacts digital 145 information flow. Politicians must decide between weak copyright 146 law, as championed by civil rights activists versus strong copyright 147 enforcement, as promoted by numerous players in the creative 148 industries. Recent furor around SOPA, PIPA, etc. in the US plus the 149 European Parliament vote on ACTA is highly relevant in this context. 151 The uniqueness of The Internet lies in the IETF standards. Moving 152 certain bits to certain locations or offering a service requires no 153 prior official approval. However, Internet-deployed mechanisms now 154 exist which filter news and media in general for both surveillance 155 and censorship. The Internet has ceased to provide reliable 156 transport service for all users. The IETF can repeat it's historical 157 inter-networking role again by setting the standard for reliable flow 158 of packets of news. 160 3. Goal: microblogging 162 The goal is creating a microblogging standard and facilitating a 163 reference implementation for portable devices which is capable of 164 operating in a hostile environment. This standard should be 165 resilient against a government Internet kill switch. Microblogging 166 is an increasingly popular technology for lightweight interaction 167 over the Internet. It differs from traditional blogging in that 168 [OPENMICRO]: 170 o Posts are short (typically less than 140 characters, which is the 171 limit in SMS). 173 o Posts are in plain text. 175 o People can reply to your posts, but not directly comment on them. 177 o People learn about your posts only if they have permission to view 178 them. 180 o Your microblogging feed is discovered based on your identity at a 181 domain or with a service. 183 This proposed draft standard SHALL provide: "information 184 dissemination from a single smartphone to an audience of millions in 185 the form of microblogging, enriched with pictures or streaming video 186 which is guarded against all known forms of censorship such as: 188 cyberspace sabotage, digital eavesdropping, infiltration, fraud, 189 Internet kill switches and lawyer-based attacks with the best known 190 protective methods". 192 The focus on microblogging is driven by feasibility. Creating a 193 standard for overcoming censorship for social networks, search 194 engines or web browsing in general is extremely challenging. 195 Mitigating the threats posed by Internet kill switches requires focus 196 on the most feasible viable standard. The related work listed in 197 this document shows existing operational systems. Existing systems 198 cover all functionality we desire, however none of them cover all 199 aspects and little interoperability exists. 201 As early as 2006, long before Arab spring events, it was reported 202 that individuals in wide swathes of the Arab world were using 203 Bluetooth technology to bypass police restrictions. According to 204 news reports[DATING], communication between men and women in this 205 region had been made possible by cellphone technology. When 206 Bluetooth-capable phones are in close proximity, they can engage 207 directly in digital and social chatter--no other infrastructure is 208 needed. Moreover, when sharing photos or bandwidth-hungry videos 209 with friends it also pays to be close. Government provided cellphone 210 networks might not be filtering you, but can still be dreadfully 211 slow. It therefore pays to use cell phones' Bluetooth-based, direct 212 file-transfer features--and it comes as no surprise that wireless- 213 transfer apps have seen millions of installs. A query of Google 214 Trends for the phrase "Bluetooth transfer" reveals a geographical 215 spread of this interesting social phenomenon[TREND]. It seems 216 millions of mobile phone owners are already employing the social 217 practice of wireless data exchange. Viability is increased by 218 building upon this practice. 220 4. Driving scenarios 222 Recent Arab spring events have shown the power of ubiquitous camera- 223 phones, new media and microblogging. This document proposes to uses 224 smartphones, wifi and USB sticks for multimedia transport and 225 playback. The architecture, features and driving scenarios are 226 specifically crafted to enable compliant implementations as a single 227 smartphone app without any additional server infrastructure. 229 Each scenario is focused on certain threats in a hostile environment. 230 The adversary becomes stronger in several of the following scenarios 231 and we also focus on the social media context. 233 4.1. 20sec scenario 235 First scenario, called "20sec", defines an open microblogging 236 standard. This first scenario duplicates existing microblogging 237 practices with an open standard in a fully decentralized setting. 238 The scenario requirements are performance equal to central-server 239 based approach (e.g. the ability to reach 20 million people in 20 240 seconds). 242 4.1.1. Adversary model: A simplistic attacker 244 Eavesdropping is a common and easy passive attack in a hostile 245 environment. In this scenario we assume the attacker has full access 246 to the network between the user and any Internet server. 247 Specifically, the adversary can observe, block, delay, replay and 248 modify all traffic coming from any server. Furthermore, all servers 249 such as DNS servers, web servers, swarm trackers, CDN cloud servers 250 and access portals are assumed to be under direct or indirect control 251 of the adversary. 253 The adversary cannot compromise traffic between smartphones or other 254 participating devices. The adversary cannot compromise smartphones 255 or other participating devices. The adversary cannot break standard 256 cryptographic primitives, such as block ciphers and message- 257 authentication codes. 259 4.1.2. Scenario details and architectural requirements 261 Smartphone owner Alice with wifi-based Internet access records an eye 262 witness video. She attaches this video to a microblog entry and 263 shares this story plus video automatically with friends Bob and 264 Charlie which are subscribed to her news feed. Alice does not need 265 to trust any central server with her credentials or has to prove her 266 identity to a central (web) server. Bob and Charlie are both behind 267 a NAT middlebox compliant to the BEHAVE recommendations [RFC4787]. 268 No assistance of a coordinating server (e.g. STUN or TURN) is 269 required to traverse this NAT box using UDP messages. This scenario 270 assumes direct or NAT-based Internet access (the next scenario deals 271 with packet forwarding). 273 Performance should be equal to central-server based approach, 274 providing the ability to reach 20 million people in 20 seconds. This 275 first scenario duplicates existing microblogging practices with an 276 open standard in a fully decentralized setting. The 20sec scenario 277 requires that solutions provide seamless backwards compatibility with 278 existing leading solutions (e.g. Twitter, Sina Weibo, chyrp, heello) 279 by using content import tools. Proposed open solutions MUST permit 280 easy bulk trans-coding and ingest of existing news feeds into this 281 open standard. 283 An essential feature of the 20sec scenario is all central gatekeepers 284 or communication to them is possibly compromised. Ownership of data 285 is fundamental to autonomy. To meet the anti-censorship goal, 20sec 286 assumes an infrastructure which is not dependent and completely 287 decoupled from potentially hostile servers such as DNS servers and 288 web servers. 20sec MUST be based on full self-organization. The 289 infrastructure consists purely of devices running compliant 290 implementations. No central server requires installation or 291 maintenance, making this infrastructure independent on any type of 292 funding or business model. 20sec requires an overlay which is highly 293 resilient. Smartphones, tablets and PCs are able to utilize this P2P 294 overlay for microblogging. Existing solutions such as [OPENMICRO] 295 require a central webserver and OAuth-like authentication primitives. 296 This prior work is not suitable for our 20sec scenario, as we aim to 297 remove all server, ultrapeer or superpeer reliance and equality of 298 all participants in the overlay. 300 When Alice downloads her smartphone app and starts it for the first 301 time it needs to bootstrap. On this initial startup, the 302 microblogging software must bootstrap and find at least one other 303 peer in the overlay. The most simple method of bootstrapping is 304 using a list of currently online peers plus their port number. See 305 the example below. 307 # file: Central-Bootstrap-Servers.txt 308 # default bootstrap peers 309 server1.always-online.org 6420 310 host1.never-offline.ro 6420 311 sealand.routed.org 6420 312 168.0.0.13 6420 314 A file sharing program needs a fresh list of peers to bootstrap. 315 Thus a pre-defined list of peers is included in the software 316 installer. As peers can go offline it is important that at least one 317 peer out of possibly thousands on the list is still online. This 318 pre-existing address list of possibly working peers must therefore 319 remain valid for as long as possible. Bootstrapping is done by 320 contacting peers in the list, possibly in parallel. If a single 321 peers replies, the smartphone app of Alice is connected. Once 322 connected, a fresh list of working peer Internet addresses COULD be 323 requested. Several ideas have been proposed on bootstrapping systems 324 without an "online bootstrap server" list. For instance, simply by 325 smart brute force pinging, as described by the University of Denver 326 [BOOTSTRAP]. 328 It is RECOMMENDED compliant implementations explore and implement 329 efficient alternatives for decentralized initial bootstrapping. 331 4.2. Kill-switch scenario 333 This scenario describes a situation without any Internet access. We 334 assume the government has essentially "killed" the Internet, in an 335 Arab spring like scenario. It is focused on ad-hoc packet forwarding 336 between smartphones. 338 4.2.1. Adversary model: An advanced attacker 340 The adversary has disabled all Internet-based communication. 342 We assume the adversary cannot eavesdrop, jam, delay, replay, modify 343 or spoof wireless communication between smartphones. The adversary 344 cannot compromise smartphones or other participating devices. The 345 adversary cannot break standard cryptographic primitives, such as 346 block ciphers and message-authentication codes. 348 4.2.2. Scenario details and architectural requirements 350 Smartphone owner Alice has no Internet access. She records a video, 351 attaches this video to a microblog entry in her phone app. Friends 352 Bob and Charlie are subscribed to her news feed. Bob and Charlie are 353 at some point within range of the wifi, bluetooth or other wireless 354 capability of Alice. This fresh microblog entry plus video is shared 355 automatically. Bob obtained the message from Alice using a 356 smartphone app which is periodically scanning if other devices are 357 around and if they possibly have fresh news. This periodic 358 synchronization SHOULD be energy-efficient. Bob sees no noticeable 359 decrease in battery lifetime after he obtained unconstrained news 360 access. Charlie later goes to a square where numerous people have 361 gathered, most of which are highly interested in the latest videos. 362 The fresh messages automatically spreads in this crowd. 364 Note that this scenario differs from Delay-Tolerant Networking (DTN), 365 as being investigated by a Working Group within the Internet Research 366 Task Force [RFC4838] and scientists[BUBBLE]. The DTN focus is on 367 finding routes to an explicitly given destination, usually by 368 maintaining routing tables. Their system model and terminology 369 cannot be applied in our context, for instance, "Endpoint 370 Identifiers" which identify the original sender and final 371 destination. In our Internet-Free scenario sender Alice does NOT 372 explicitly send a message with destination Bob. 374 A wealth of related work exists in this area. General solutions are 375 found in mobile ad hoc networks (MANET), which provide self-organized 376 IP routing among wireless devices, and delay-tolerant networks (DTN), 377 which use a simple store-and-forward primitive to communicate over 378 heterogeneous links. Mobile ad hoc networks have been studied within 379 the Internet Research Task Force (IRTF) since 1997, leading to 380 several standards published by the IETF's MANET Working Group, while 381 delay-tolerant networks are currently the focus of the IRTF's DTN 382 Research Group. We hope that much of that knowledge can be reused, 383 despite our scenario differing slightly from DTN (as being 384 investigated by the IRTF [RFC4838]) 386 4.3. friend-to-friend scenario 388 This third scenario uses friend-to-friend networking to remove the 389 requirement for active networking and wifi sensing. The smartphones 390 of Alice and Bob need to be synced manually. This scenario SHOULD 391 deliver a privacy-by-design type of microblogging service. 393 4.3.1. Adversary model: A powerful attacker 395 We must assume from the Arab Spring scenario the existence of a 396 powerful adversary. For instance, the adversary has disabled all 397 Internet-based communication. The adversary even actively monitors 398 wireless communication. Protocol designers have identified the 399 following threats [BRIAR] for similar circumstances: 401 o The adversary can observe, block, delay, replay, and modify 402 traffic on the underlying network. Thus, the microblogging 403 service must ensure end-to-end security without relying on the 404 security of the underlying network. 406 o Wireless communication is regularly monitored. Responding to any 407 wireless requests from a stranger is a direct threat to the user 408 and extremely harmful. 410 o Possession of encrypted electronic messages or encryption 411 technology in general is extremely harmful to the smartphone 412 owner. 414 o The adversary has a limited ability to compromise smartphones or 415 other participating devices. If a device is compromised, the 416 adversary can access any information held in the device's volatile 417 memory or persistent storage. 419 o The adversary can choose the data written to the microblogging 420 layer by higher protocol layers. 422 o The adversary cannot break standard cryptographic primitives, such 423 as block ciphers and message-authentication codes. 425 Encryption is not a sufficient requirement of the friend-to-friend 426 scenario, everything MUST be hidden. Possession of smartphones apps 427 with encryption is already dangerous for the owner. 429 4.3.2. Scenario details and architectural requirements 431 Reports from repressive regions indicate that USB sticks are commonly 432 used to transport sensitive information. See for instance this 433 extensive report on North-Korea [NKOREA]. In the friend-to-friend 434 scenario a network of friends is trusted to transport news manually, 435 by simply carrying it around. Smartphones with NFC capability or 436 manual USB transfer are used to duplicate and move messages. Thus 437 Alice delivers her fresh news message to Bob, which is later given 438 manually to Charlie. 440 As direct social connections are sparse and proximity of friends is 441 not continuous, this scenario SHOULD facilitate usage of friends-of- 442 friends or further removed social ties to relay news messages. This 443 requires the development of a decentralized social network, for 444 instance, with digital signatures of friendship certificates. In 445 effect this would create a "decentralized social network", completely 446 autonomous and owned by all participants. We assume Alice only has 447 Bob in her friendlist and Bob only has Charlie in his friendlist. An 448 OPTIONAL feature is that the smartphone apps running on the 449 smartphone Alice and Charlie detect that they have friendship path 450 through Bob. Fresh news is thus exchanged. 452 The interception of a single smartphone MUST NOT expose the app 453 itself, any friend list or worst: the entire social network. We 454 assume Alice is placing herself in danger with electronic tools for 455 "subversive activities against the democratic republic". Information 456 hiding techniques are essential or even life-critical. Possibly 457 based on Zero-Knowledge Proof (ZKP) protocols [ZEROKNOW]. The 458 smartphone app MUST pose as a harmless entertainment feature of a 459 smartphone or use another mechanism to become a "stealth app". 461 This scenario requires modification and enhancement based on real- 462 world experience from human rights activist [EGYPTSTUDY]. 464 4.4. Transmorph ability 466 Prior scenarios expanded the threat model. This and the following 467 scenarios are focused on the social media context. News is created 468 in a region without freedom and then needs to travel to the outside 469 world. We refer to this simply as the freedom/non-freedom border. 470 Different transport protocols, dynamics and different solutions are 471 needed on the two sides of this border. 473 We now expand the friend-to-friend scenario with a transmorph 474 ability, the ability of news to cross the freedom/non-freedom border. 476 Alice is a well known blogger in an region with extreme censorship. 477 Her identity on Twitter has millions of followers. However, she has 478 no direct ability to reach a Twitter.com server or Internet in 479 general. We assume Alice only has Bob in her friendlist and Bob only 480 has Charlie in his friendlist. Charlie is able to smuggle a 481 collection of messages out of the country. The messages originating 482 from Alice should be transmorphed into a series of Twitter post 483 belonging to her. 485 The identities used in Twitter are highly identifiable labels, with a 486 certain trust level. This hard identity with millions of followers 487 is a stark contrasts with anonymity. Current anti-censorship 488 technology lacks the ability to first have stealth encrypted 489 transport of news, cross the freedom/non-freedom border and then 490 transmorph this news into a public accessible form with a highly 491 identifiable label. 493 4.5. A single global conversation 495 Existing technologies, such as [TOR] in combination with XMPP or the 496 Orbot smartphone app facilitate protected point-to-point 497 communication. However, a desired scenario is to facilitate more 498 current the Twitter-like social media practices, best typified as a 499 "global conversation". 501 Furthermore, current social media revolves around video-rich, real- 502 time interaction with groups, hashtag-based discovery and social 503 networking. All of these aspects are not offered or are incompatible 504 with current-generation of privacy enhancing technology. More 505 knowledge is needed about reputation models in news reporting and 506 information flows. In the current microblogging age, does the number 507 of real-person followers be seen as your reputation? Do several news 508 sources of moderate reputation which report the same news story yield 509 together an increased reputation score? 511 This work should combine privacy enhancement with microblogging. 513 4.6. Spammers and hoaxes 515 This final scenario is focused on spam. All technology addressing 516 one of the above scenarios MUST also have the capability to deal with 517 spam. Unfortunately, this ability to deal with spam is in conflict 518 with simplicity. 520 Alice and Bob are exchanging the fresh messages from their social 521 network (similar to Internet-free or Friends-only). Eve is actively 522 trying to disrupt the system by injecting news channels with a mix of 523 genuine news, obviously fake messages (consuming valuable system 524 resources and user attention) and hoaxes. These falsehoods made to 525 masquerade as truth result in erosion of overall trust in the system. 527 Systems SHOULD offer capabilities to report spam, mechanisms for fact 528 validation and reputations of (pseudo) identities. 530 5. Design principles: simplicity and prior success 532 Designing and crafting software which is completely self-organizing 533 has clear limits [CAPLIMIT] and requires a certain level of expertise 534 [LEVELS]. In order to avoid repeating mistakes from the past, this 535 document aims to base itA's design principles on existing new media 536 successes. For microblogging this means following market leading 537 solutions and enhance them with censorship resilience. We recognize 538 the following success factors: Simplicity, Real-time responsiveness, 539 Near-effortless news creation, News items are bundled in channels, 540 combine public broadcasting and person-to-person private messaging, 541 following a channel is single direction, more followers yields more 542 visibility, keyword search with push of updates and ability to deal 543 with spam. 545 6. Background rant: lack of coordination and fragmentation 547 Computers communicating on equal footing has been part of the IETF 548 standards for many decades. Recently several loosely connected 549 standard initiated around explicitly driven by the P2P paradigm for 550 applications such as Internet telephony video streaming. An 551 essential problem in this domain is the lack of coordination and 552 standard setting for P2P technology. A large part of the innovation 553 around P2P seems to happen in single-person Open Source projects and 554 small groups which lack the engineering capacity to make generic, re- 555 usable and documented components. Given their running code-driven 556 nature, money and time is not available for attending standards- 557 setting meetings, writing formal specifications and defining quality 558 control testing suites. Profit-driven organizations should have the 559 resources to overcome these resource shortage issues. However, due 560 to the dynamic, disruptive and litigious nature of P2P few examples 561 exist of companies which are capable of supporting an IETF standard 562 setting activity for several years. 564 As presented during IETF 81 area directorate, there is "not a clear 565 long-term architecture yet for you to build actual classes of P2P 566 applications using IETF technologies". Forming an overlay is hard 567 and scalable privacy-preserving unstructured search solutions are 568 only barely out of the scientific research community. 570 From the above we conclude that a key obstacle to the success of this 571 proposal is implementation and uptake. A draft document, active 572 community and reference implementation ideally evolve together over 573 time. To overcome this issue a continuous incremental improvement 574 approach is advised. The preferred way is incremental development of 575 single a reference implementation, based on free software. 577 7. Current running code and related work 579 DISCLAIMER: this section needs significant expansion and listing of 580 projects with running code and self-organization. 582 Several Open Source projects have running code and partially 583 implemented the above four scenarios. We will briefly list them 584 here. 586 [TOR] A free software implementation of second-generation onion 587 routing, a system enabling its users to communicate anonymously on 588 the Internet. This flagship project has boosted online anonymity for 589 over a decade and the key example for the cat and mouse dynamics. 590 The Orbot project provides an Android implementation of Tor. Due to 591 the usage of the client server/model, exit node principle plus lack 592 of reputations this architecture is not compatible with our 593 scenarios. 595 [DIASPORA] A free personal web server that implements a distributed 596 social networking service. This partially operational system is 597 based on the client/server model and not compatible with our ad-hoc 598 scenarios. 600 [BRIAR] Briar is a secure news and discussion system designed to be 601 used by journalists, activists and civil society groups in 602 authoritarian countries. Briar differs from existing circumvention 603 tools and mesh networks in three significant ways: needs no external 604 infrastructure, can operate over any mixture of available media and 605 builds on social relationships. The aims of this project are similar 606 to our scenarios, but this project lacks running code and has few 607 active developers. 609 [BUBBLE] DTN researchers have simulated closely related scenarios. 610 Dissemination in the Arab Spring scenario is likely to involve an 611 explicit copy between people who trust each other, referred to as 612 social-based forwarding in this study. 614 [TWIMIGHT] The Twimight project by ETH-Zurich university shows that 615 decentralized microblogging already exists. Researchers developed an 616 Android application that uses Twitter servers in normal conditions, 617 but switches to a Bluetooth-based disaster mode when Internet 618 connectivity is lost. 620 [MUSUBI] The Musubi smartphone app represents another key, 621 censorship-free, technology advancement. Developed by Stanford 622 University, it offers instant messaging service and media sharing 623 capabilities similar to WhatsApp, Ping, and Blackberry Messenger. 624 What makes it unique is that all data and processing resides on the 625 smartphones, not in the cloud. This decentralization removes the 626 need for central processing and provides significant decoupling from 627 the underlying infrastructure. Exchange of cryptographic keys is 628 integrated in the friending process--Musubi essentially builds a 629 decentralized social graph. Unfortunately, Musubi is also limited-- 630 all data transfers go through central servers, as it lacks NAT- 631 traversal capability. 633 [TRIBLER] DISCLAIMER2: this project is coordinated by the author. 634 This project has created Open Source firmware for a Samsung Internet- 635 connected television which gives it the ability to find, share and 636 stream news videos within a fully self-organizing overlay; operated 637 only by remote control [REBELLIONTV]. It is also available as 638 generic zero-server file sharing software for the PC which has been 639 installed by 1.2 million users. It uses the Dispersy elastic 640 database for providing: keyword search, content discovery, content 641 voting and spam prevention using crowd sourcing [DISPERSY]. For 642 swarm-based streaming and generic message transport it uses the IETF 643 protocol developed within the PPSP working group, called Libswift 644 [LIBSWIFT]. All this code is created by a single team and 645 specifically designed to facilitate evolution into the prior 646 described scenarios. An Libswift demo streaming app is available on 647 the Android market. 649 8. Open issues 651 Deliverables planned and issues which need to be addressed. 653 TODO: ADD REF Privacy definition: 654 http://tools.ietf.org/html/draft-iab-privacy-terminology-01 656 TODO: REF 657 http://www.ietf.org/id/draft-iab-privacy-considerations-03.txt 659 TODO: http://datatracker.ietf.org/doc/search/ P2P 661 TODO: http://datatracker.ietf.org/doc/rfc4981/ SEARCH survey 663 TODO: https://datatracker.ietf.org/doc/draft-ietf-p2psip-reload/ 665 8.1. Use cases and threat model 667 8.2. System components, definitions and system architecture 669 8.3. Current technology and gap 671 8.4. Detailed system design and protocol specification 673 9. Security Considerations 675 tbd. 677 10. IANA Considerations 679 tbd. 681 11. References 683 11.1. Normative References 685 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 686 Requirement Levels", BCP 14, RFC 2119, March 1997. 688 11.2. Informative References 690 [RFC4787] Audet, F. and C. Jennings, "Network Address 691 Translation (NAT) Behavioral Requirements for Unicast 692 UDP", BCP 127, RFC 4787, January 2007. 694 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., 695 Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay- 696 Tolerant Networking Architecture", RFC 4838, 697 April 2007. 699 11.3. URL References 701 [YOUTH] http://www.nytimes.com/2009/01/25/magazine/ 702 25bloggers-t.html, "Revolution, Facebook-Style". 704 [FORCEDLOGIN] http://online.wsj.com/article/ 705 SB125978649644673331.html, "Iranian Crackdown Goes 706 Global". 708 [NKOREA] http://audiencescapes.org/sites/default/files/ 709 Report_Summary_Quiet_Opening_North% 710 20Korea_InterMedia.pdf, "A QUIET OPENING: NORTH 711 KOREANS IN A CHANGING MEDIA ENVIRONMENT". 713 [EGYPTSTUDY] http://conferences.sigcomm.org/imc/2011/docs/p1.pdf, 714 "Analysis of country-wide internet outages caused by 715 censorship". 717 [OPENMICRO] http://xmpp.org/extensions/xep-0277.html, "XEP-0277: 718 Microblogging over XMPP". 720 [DATING] http://www.washingtonpost.com/wp-dyn/content/article/ 721 2006/08/05/AR2006080500930.html, "Saudi Youth Use 722 Cellphone Savvy To Outwit the Sentries of Romance". 724 [TREND] http://www.google.com/trends/?q=bluetooth+transfer, 725 "Google Trends query". 727 [BOOTSTRAP] http://grothoff.org/christian/dasp2p.pdf, 728 "Bootstrapping Peer-to-Peer Networks". 730 [ZEROKNOW] http://www.cse.ust.hk/~liu/luli/PT_Trans_final.pdf, 731 "Pseudo trust: Zero-knowledge based authentication in 732 anonymous peer-to-peer protocols". 734 [CAPLIMIT] http://doi.ieeecomputersociety.org/10.1109/MC.2012.54, 735 "The CAP Theorem's Growing Impact". 737 [LEVELS] http://blog.incubaid.com/2012/03/28/ 738 the-game-of-distributed-systems-programming-which- 739 level-are-you/, "The Game of Distributed Systems 740 Programming. Which Level Are You?". 742 [TOR] http://www.torproject.org, "Tor Project: Anonymity 743 Online". 745 [DIASPORA] http://diasporaproject.org/, "Diaspora is a fun and 746 creative community that puts you in control.". 748 [BRIAR] https://fulpool.org/btp.pdf, "Secure communication 749 over diverse transports". 751 [BUBBLE] http://dx.doi.org/10.1109/TMC.2010.246, "BUBBLE Rap: 752 Social-Based Forwarding in Delay-Tolerant Networks". 754 [TWIMIGHT] http://dl.acm.org/citation.cfm?id=2159576.2159601, 755 "Twitter in disaster mode: smart probing for 756 opportunistic peers". 758 [MUSUBI] http://dl.acm.org/citation.cfm?id=2187866, "Musubi: 759 disintermediated interactive social feeds for mobile 760 devices". 762 [TRIBLER] http://dl.acm.org/citation.cfm?id=2206767, "Tribler: 763 P2P search, share and stream". 765 [REBELLIONTV] http://www.tribler.org/trac/wiki/SwiftTV, "RebellionTV 766 a.k.a. Libswift on a television project". 768 [DISPERSY] www.frayja.com/pub/ 769 dispersypaper2012.pdf:donotdistribute, "Dispersy 770 elastic database". 772 [LIBSWIFT] http://www.libswift.org, "IETF PPSP streaming protocol 773 implementation". 775 Author's Address 777 Johan Pouwelse (editor) 778 Delft University of Technology 779 Mekelweg 4 780 Delft 781 The Netherlands 783 Phone: +31 15 278 2539 784 EMail: J.A.pouwelse@tudelft.nl