Dear All, Last IETF in Atlanta a side meeting was held about "media without censorship". Brief conclusion: - a large group of people is interested in this topic - implementation of ideas is judged to be key - difficult to fit in IETF, but other organisations are worse.
Discussion I-D: http://tools.ietf.org/html/draft-pouwelse-censorfree-scenarios-02 First, many thanks to all of the attendants for their valuable feedback. Especially given the overloaded schedules of many people present. It was a very productive meeting in my personal opinion. [informal meeting notes] Roughly 18 people attended a late-night side meeting at 21:00 on 8 November in Atlanta. It was taking place right after the bits&bites free drink event, lifting the general spirit so to say. The improvised proposed agenda included: goal discussion, scenario discussion, prior technology and gap between vision/current tech, system architecture: sunshine model. Discussed was the similarity between the Tor anonymous browsing experience and the censorship free scenarios. Key difference is the reputation system. It was noted that the adversary model has unrealistic assumptions. The increase of attackers power and increasing demands on solutions was not sufficiently clear to readers. Should be removed or clarified. A key question raised was: why does this need an IETF standard? This turned out to be surprisingly difficult to answer. 1) in IETF it is possible to obtain feedback from experienced engineers on architecture and design ideas. IETF people give valuable real-world experience based feedback, differing/complimenting from academia setting, Open Source world and digital human-rights activists. 2) it would produce clear specifications which could unite currently fragmented prototype-driven initiatives. Given this, is then the IETF really the right venue for this? The I-D is vague about the physical layer. It can simply be: Bluetooth, direct wifi, NFC and manual USB-stick based transport of information. Needs to be clarified. The threat model was discussed further and deemed missing the evolution of the adversary. The "Continuous evolution scenario" could be added. Draft explanation: Due to the nature of an open standard against censorship, the inner workings of all mechanisms are known to the attacker. At some point it is likely to become compromised due to attacker evolution. To be future proof, the standard needs to be able to co-evolve and be able to include new defensive capabilities. A draft picture of the possible architecture of the system model was discussed, called "sunshine model". The inner part contains the nodes in the system with high-speed Internet connectivity without censorship. They form the core of the system with possibly millions of participants, coming online and going offline regularly. Nodes at the core experience churn, but can always connect freely to other online nodes in the core (using NAT puncturing possibly) The "rays of sunlight" are nodes without media freedom and constrained Internet. Information transfer between these nodes uses DTN-like techniques and Bluetooth, NFC, direct wifi or USB drives. Key components in the proposed system architecture are the message forwarding and reputation, voting or spam prevention part. For the message forwarding, significant overlap exists with the bundle protocols of DTNs. The term "bundle synchronization" was introduced, meaning exchanging all known new twitter-like messages between two nodes when they are near. The security in DTN work was discussed, as the anti-censorship scenarios place heavy demands on this. Voting protocols is something the IETF seems to have done little work in. Crowdsourcing and spam prevention is known to be a difficult problem in a fully distributed setting. Other concerns raised: "what is the meat", "we have all this". An important step forward is to create an implementation with re-usage of existing software + usage of IETF standards where possible. [I lost track of the reasoning behind the importance of an implementation] Please enlighten me if an attendant remembers this. Near the end of our 1 hour meeting it was noted that "the IETF is good at efficient data-communication protocols, but this is counter-intuitive". Implying that this work lies outside the usual IETF 'comfort zone'. Greetings from Holland, johan. On 9 November 2012 16:06, Martin Stiemerling <[email protected]>wrote: > Johan, > > It would be good if you could write a summary about the last night's > meeting and post it to the privacy list. > > The key message of the room was 'get it implemented' and come back > afterwards. I have seen that the DTNRG co-chairs (Jörg and Kevin) where > rather positive about it. I.e., it might be good to stay in contact with > them and if you have an implementation by the next IETF meeting, it might > be good to see if this could be shown & explained in the DTNRG, if it is > based on DTN. > > Martin > > > On 11/07/2012 10:21 PM, Johan Pouwelse wrote: > >> [apologies for double posting] >> Please attend this side meeting at IETF 85 if you are interested. >> >> Vincent Roca was kind enough to do the first extensive review of the >> discussion I-D for that event. Reaction inline below. >> >> On Tuesday, November 6, 2012, Vincent Roca wrote: >> >> 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. >> >> >> This is indeed strange and only meant as a simplistic starting scenario. >> >> 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. >> >> >> Indeed, the idea as to have progression in the threat model. >> In the next version I will try to make that clearer. >> Or if you think that is not a good idea, it can be changed. >> >> 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? >> >> >> Again done for simplicity. >> >> 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 ;-) >> >> >> Yes, thank you for spotting this. It implicitly assumes wired Internet >> and usable connections. >> Will clarify this. >> >> 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) >> >> >> Another clarification needed.. The idea is that the attacker can do a >> chosen plain text attack. >> >> 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 >> >> >> Interesting work! Will use this in next version. >> Never knew that your listen port number is actually privacy leakage in a >> DHT. >> >> I'll be at the side-meeting. >> >> >> Looking forward to it. -j >> >> Cheers, >> Vincent >> >> >> >> ______________________________**_________________ >> ietf-privacy mailing list >> [email protected] >> https://www.ietf.org/mailman/**listinfo/ietf-privacy<https://www.ietf.org/mailman/listinfo/ietf-privacy> >> >>
_______________________________________________ ietf-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-privacy
