Re: [perpass] perens-perpass-appropriate-response-01

Jacob Appelbaum <> Sat, 07 December 2013 10:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1131F1AE2CB for <>; Sat, 7 Dec 2013 02:47:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.6
X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=2, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1dH_hnu26_co for <>; Sat, 7 Dec 2013 02:47:48 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 490A41AD694 for <>; Sat, 7 Dec 2013 02:47:48 -0800 (PST)
Received: by with SMTP id v10so675117bkz.21 for <>; Sat, 07 Dec 2013 02:47:43 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=D5aHl9DloO0QeGAGPngfcRBWSJmBxmFE22ZZnKO8SLg=; b=TJsmaqJW2vcepsNZkVLc67QzSPttpeZB2L24C/gHKRTorI5Fgr2QKtsajxR61Zlnlo T/9JYN4xVRMDVgbFHlAsf0vutn00yt0ONAk89oY1yqIrOOPuzdIxvzo7+1cHQdkWE66E 93PNrAsR4EWjt5etlslgDf7SWwiz2HWpZpmi110deWc0jCGSa+xRaFNyiNfmnhhidKfZ 1WS8+qfxdfQp9ka1J7zLDT6dsEKtz/famhkFluYV3mixGd7e+D7K5SONo8ysm4UJhtLm tCejClRvFvZNvq6F2h+orroDzxXue7XfjCkGZqI8v9EZ+JGIkW1aUvecQiupwRv4Lgtf dYww==
X-Gm-Message-State: ALoCoQnccwO1GBqDet7HTeGDQbgodaFGkk0+LO/zO2ZtKkghQ/u9TdQ1MNHocA3RIUNFQCO/+aPq
X-Received: by with SMTP id pg10mr35379bkb.158.1386413263713; Sat, 07 Dec 2013 02:47:43 -0800 (PST)
Received: from ( []) by with ESMTPSA id sx5sm1572748bkb.0.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Dec 2013 02:47:42 -0800 (PST)
Message-ID: <>
Date: Sat, 07 Dec 2013 10:11:57 +0000
From: Jacob Appelbaum <>
MIME-Version: 1.0
To: Bruce Perens <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
OpenPGP: id=4193A197
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: perpass <>, John Wroclawski <>
Subject: Re: [perpass] perens-perpass-appropriate-response-01
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 07 Dec 2013 10:47:50 -0000

Bruce Perens:
> John,
> Of course I have sympathy for all of those who have their human rights abridged, 
> and would not begrudge them the use of Tor, preferential https, or whatever 
> helps. 

Really? Where is your sympathy exactly? I am one of those who have my
human rights abridged, as is everyone on this list, I might add. It is
nearly impossible for me to protect myself, even with Tor, because
nearly all services and systems are insecure in the face of specific
attacker capabilities.

Is your sympathy simply that you begrudgingly will allow us to protect
ourselves from your (and my) spy agency, the NSA? Some sympathy!

> I am not sanguine that encryption is any barrier to NSA due to the ASIC 
> issue previously discussed, but it might well be a barrier to religious 
> extremist oppressors, etc.

Do you understand how the TURMOIL and TURBINE programs work? The first
is a passive sensor system that does DPI (Deep Packet Inspection) and
the second is an active sensor system that does DPI (Deep Packet Injection).

The TURMOIL system is used for protocol classification and selector
based surveillance. The TURBINE system takes actions, usually packet
injections for Man-on-the-Side, based on the results of TURMOIL and
similar systems.

For any agency to build a system like TURMOIL, they must be able to scan
the traffic in real time. The time to race a TCP connection is very
small and as it stands, they do not win all of the time - latency of
injection provides enough variance to stop QUANTUMINSERTION related attacks.

Do you have any evidence that these systems use super computer, ASIC or
FGPA based decryption techniques as part of the TURMOIL or TURBINE programs?

It is clear that they do decryption from captured and stored data. It is
also clear that they cannot store *everything* and so traffic analysis
is part of how they decide what to store and thus how they are able to
record the ciphertext for later attacks. Only basic traffic analysis
resistance in common protocols will start to change this balance.

This is part of how we will end massive surveillance of the internet. We
will not end mass surveillance by keeping the current economic balance
and the current social cost that is afforded to these spies and other

> The problem with security is that however much you have is never enough, because 
> there's always a new threat. And that is exactly why the United States is 
> pursuing a continuously increasing war in whiich surveilance and odious security 
> procedures only increase. And thus IETF will also end up on a continuously 
> increasing war in which odious security procedures only increase, in response.

This is false.

A key problem here is that you refuse to acknowledge that well known,
even practically solved problems, are a threat to the users of the internet.

TLS for HTTP will reduce the attack surface of every computer from third
party network based threats. We can very nearly eliminate these threats
entirely and we can ensure that when the threat becomes reality, we may
detect it and fail in a closed manner.

> The next step after encrypting every web query is locking down the browser to 
> the "trusted platform" and insisting on identifying certificates for all users. 
> Our various corporate totalitarians are sure to want it, it already exists on 
> the iPhone and other DRM platforms, and will only get tighter.

This is a red herring and is also false.

> So, this ends with the death of the open web.

The NSA has killed the open web as we know it. The Chinese "Great"
firewall has killed the open web that most of China *never* knew anyway.

> At some point, we have to draw a line and say this is enough, it doesn't really 
> protect us, it protects someone else at our expense.

The question I ask myself, Bruce, is if at some point, you're working to
the benefit of someone else? You certainly don't seem to care about the
common good in the face of real threats because of your privilege as a
US citizen and your general arrogance rooted in other privileges.

> Where do you propose to do that? Right after _this_ change? And when the next 
> proposal is to draw the line right after the _next_ change, and so on ad infinitum?

Attacks generally improve over time. We must iterate on protocols that
have serious flaws and ensure that we defend against attackers.

> So, I don't want to be forced onto this next security upgrade. I want to be able 
> to intelligently decide whether I need it and when, and to control whether I use 
> it, and when to dispense with it when it's being used for things that areck not in 
> my interest.

You're apparently not doing that now, why will you do that later?

You're not being forced to do anything, are you? You could use HTTP 1.1
forever, right? Oh right, sometimes choice is removed! How does it feel
to be like the rest of the world for just one moment?