Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA

Martin Millnert <martin@millnert.se> Fri, 06 September 2013 04:37 UTC

Return-Path: <martin@millnert.se>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3FE11E823F for <ietf@ietfa.amsl.com>; Thu, 5 Sep 2013 21:37:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.583
X-Spam-Level: *
X-Spam-Status: No, score=1.583 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALuPtLat1b4o for <ietf@ietfa.amsl.com>; Thu, 5 Sep 2013 21:37:02 -0700 (PDT)
Received: from mail.millnert.se (unknown [95.80.32.84]) by ietfa.amsl.com (Postfix) with ESMTP id 6C73211E8265 for <ietf@ietf.org>; Thu, 5 Sep 2013 21:37:00 -0700 (PDT)
Received: from [10.4.221.8] (unknown [94.234.170.31]) by mail.millnert.se (Postfix) with ESMTPSA id 7DED1B8; Fri, 6 Sep 2013 06:38:12 +0200 (CEST)
References: <20130906033934.F1EC418C126@mercury.lcs.mit.edu>
Mime-Version: 1.0 (1.0)
In-Reply-To: <20130906033934.F1EC418C126@mercury.lcs.mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail-ED37BC97-7279-4AFB-B85C-C205BD0F3F69"
Content-Transfer-Encoding: 7bit
Message-Id: <9368D8DE-E1C8-4B72-9F82-A5E22C39EFFC@millnert.se>
X-Mailer: iPad Mail (10B329)
From: Martin Millnert <martin@millnert.se>
Subject: Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
Date: Fri, 06 Sep 2013 06:36:50 +0200
To: Noel Chiappa <jnc@mercury.lcs.mit.edu>
Cc: "ietf@ietf.org" <ietf@ietf.org>, "jnc@mercury.lcs.mit.edu" <jnc@mercury.lcs.mit.edu>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Sep 2013 04:37:07 -0000

On 6 sep 2013, at 05:39, jnc@mercury.lcs.mit.edu (Noel Chiappa) wrote:

>> From: Phillip Hallam-Baker <hallam@gmail.com>
> 
>> S/MIME is almost what we need to secure email.
> 
> If by "secure email" you mean 'render email impervious to being looked at
> while on the wire', perhaps. If, however, you mean 'render it secure from
> ever being looked at by anyone else', no way.
> 
> Even if it's stored on the destination host in encrypted form, if that host is
> compromised, the contents of that email are now at risk. Even if the key is
> not stored on that machine, the next time it's entered into that machine (or,
> more broadly, the encrypted email and the key are brought near each other), it
> can be lifted, _if that computer has been compromised_.

This and several other comments about the endpoint threat thus far in this thread does not seem to understand a very vital point:
Bruce was in http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance not suggesting that more encryption on the wire by open protocols can starve off attacks on endpoints.
He was not suggesting that backdoors in eg. network driver's firmwares cannot provide special access to host memory, extremely hard to detect and never utilized in friendly territories where raw opto tapping provides cheaper access anyway.

But he IS suggesting that encrypting everything on the wire makes both metadata and payload collection from wires less valuable.
Here comes the key point:
Encrypting everything on the wire raises the cost for untargeted mass surveillance significantly. And that is what it is all about.

And best is of course if this can be end to end, though hiding metadata requires either something onion like or transport encryption by layers below said metadata.

/M