Hi, >> I believe that where encryption is not actually *used*, pervasice >> monitoring *will* happen. Or, to state it a bit more in a logic-oriented >> way: >> >> Either the use of encryption proliferates, or the use of pervasive >> monitoring proliferates. >> >> It is a strict XOR: you can't have both, and you can't have none of the two. > > Pervasive monitoring is not just about encryption, and I suspect you > fully understand this, but have simplified your argument for the > purposes of focusing on encryption.
Well, yes, the thread was massively around encryption (which was probably off-topic (sorry), as perpass doesn't explicitly touch this). > Even so, I like your analogy, in as > much as you are not looking at one big XOR but many little small ones > and then summing them on either side of the equation. That's the nature > of engineering tradeoffs, to be fair. I think my main point is that the world at large wasn't aware that there is an equation at play at all. For a very long time we (for some definition of we; I suggest "internet users") thought that when lowering the encryption/privacy/etc. side, there would be no adverse effect; essentially thinking "Nah, there is nobody who wants to exploit my not-very-important data, and nobody would be able to do this on a big scale anyway; we can afford to ignore/depriorise security properties". What we've learned from the Snowden documents is that we have to expect capable adversaries to be at all the important spots who will merrily exploit any opportunity we give them and make the most out of it. They even collect our digital junk and find it a valuable asset. Only at that point did it become clear that there actually *is* an equation, and that the other side of the equation is an ugly-looking beast. And by consequence, that any lapse on our side of the equation will have an effect on the other side. (To be fair, the equation is of course a lot more complicated than my simplistic XOR ;-) ) In a way, using the same half-baked mathemetical expression repertoire: perpass attacks are a function of encryption, authentication, traffic volume analysis, ...; or: f(level of use of encrpytion, level of use of anonymity, level of use of traffic volume concealment, ...) = actual surveillance level Before Snowden, I would not have put an equals there, but merely: "presents an upper bound for". I have become less optimistic :-/ We should tune all parameters of the function to minimise the outcome of the function; under the condition of keeping in mind that the left side should still remain *usable* with this tuning in place. > Masking the "who" is much harder than the what, and yet the "who" may be > as or more valuable. Unfortunately for us, the who can be represented > by IP address (as an example). It's why there's some interest in TOR. > Fortunately for us, use of services like Google or Facebook or Twitter > provide a means to obscure paths of communication. Unfortunately for > us, they become single points of failure.[*] Thanks for the link to the paper, a good read! It suggests there's not just something to be learned from "who" and "what" but also the "how much". One of the reasons why I jumped on the encryption part of things is because I consider those to be the low-hanging fruit - it's the "what". About the what: Developing encryption for protocols is "what we do", so doing more of that comes easy. About the who: very exact and deterministic routing of packets to known IP addresses is what we do. Changing things towards introducing untracable, indeterministic detours and artificially making communication less effective by creating noise is not what we usually do. So working in that area is harder. If we don't mind taking non-IETF work into our hands we could of course say: every router MUST TOR (both for outgoing user payload, and as a relay and exit node) - but do we want that? The implications on traffic volume and routing efficiency are totally non-obvious. About the "how much", only a crazy idea: it would be kind of nice to have a program on every internet user's computer who "keeps the line busy" at all times. Equipped with a random selection of URLs to visit, it just downloads stuff and moves it to /dev/null. Just to make the SNR to a passive listener uninteresting. An external viewer can't determine if a URL was automated junk download or something the user actually saw. Such a scheme would make perpass attacks much less useful, all without encryption. It could even help with plausible deniability in case a government finds a particularly "bad" URL was visited by the user - it's quite plausible that it was not him, but some daemon on his machine, and the user never saw the result of the download. Google has a pretty good DB of URLs to visit - and it's even largely copyright-infringement clean, because the copyright holders are nice enough to force Google to cleanse infringing entries. Thanks! Greetings, Stefan Winter > This goes to a point that Mark Nottingham made in the plenary. How do > we strike a balance between those single points of failure on the one > hand and the potential benefits that some amount of aggregation can > bring? There has been other related work on this topic from the context > of platform diversity and cybersecurity, but I regret that I couldn't > find the paper I wanted to cite for this email (I tried- it's there- > maybe others can dig it up) that is worth some consideration. > > My point in raising this now and my point of intervening several times > in the plenary is to highlight that many of the issues around pervasive > surveillance are complex and have many tradeoffs to be made. There's > some research to be reviewed, and perhaps some research to be > performed. When we say that we the IETF are going to do something, we > need to be looking at a long term view, while taking reasonable actions > in the short term that heads us in the right direction. > > Eliot > > [1] http://weis2006.econinfosec.org/docs/36.pdf > [*] I imagine there's an undiscovered Rogers and Hammerstein song called > "Fortunately/Unfortunately" buried in here. -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
0x8A39DC66.asc
Description: application/pgp-keys
0x8A39DC66.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
