Re: The CIA mentions us

willi uebelherr <> Fri, 10 March 2017 02:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D572812947E for <>; Thu, 9 Mar 2017 18:49:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.722
X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2B178-ZyGMRX for <>; Thu, 9 Mar 2017 18:49:16 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 661731294DF for <>; Thu, 9 Mar 2017 18:49:16 -0800 (PST)
Received: from (unknown []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by (Postfix) with ESMTPS id 10F771A2101 for <>; Fri, 10 Mar 2017 00:29:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=squak; t=1489105767; bh=NpzJTi87zB9CX2ir6scoFuXB8v4OOxczaGesVEwpdgc=; h=Subject:References:From:To:Date:In-Reply-To:From; b=Uz512KEQqamQ8HwhNGfn57Tm0y2BSrSid4G1gLrnu0ZHICq061v54dfC6XIaarLUg dEHSH++N5TN+RMj4kfWu84UVRn7R8ykopagbliL7qu8z0gmhu3Jr5ch78M/6UvUbxI vQZLvene9xrvApTJumxjg0jJWXYKupEXZRMoqk4Q=
Received: from [] (localhost []) (Authenticated sender: willi.uebelherr) with ESMTPSA id E56C01C25B1
Subject: Re: The CIA mentions us
References: <> <> <> <> <> <> <> <> <00A55B3A256BD71DFB1866B4@PSB> <>
From: willi uebelherr <>
To: IETF discussion <>
Message-ID: <>
Date: Thu, 9 Mar 2017 21:28:53 -0300
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Mar 2017 02:49:18 -0000

Dear Phillip,

i follow your highly interesting discussion. Many thanks.

We can say, not always we need the encryption of our data. But if we 
need it, we have to do it.

End to end encryption means person to person. In this example of IETF 
discussion list, this means, that i need the encryption key with you, 
Phillip. Independent of mailbox or maillist servers. The data in the 
mailbox and in the maillist and maillist archive are encrypted. And if 
we use a strong algorithm base, nobody others can read the data in the 
email. Only Phillip and Willi.

The encryption from you to the receiver list makes no sense. And if we 
published any text for many people, encryption makes no sense too.

Patent law. You speak about. For me, every patent right is a criminal 
task. Therefore, it don't exist for me. The knowledge is always world 
heritage. Therefore, we can use every algorithm, what we want.

many greetings, willi

On 09/03/2017 18:11, Phillip Hallam-Baker wrote:
> There are two issues
> 1) Requirements, how should this data be secured?
> 2) Technology, how can the requirements be met?
> I totally agree that transport layer encryption is not enough here. The
> security requirement is end to end.
> Proprietary products that meet that requirement do exist and the US
> agencies that do this work have the financial and technical means to deploy
> and use them and I have no problem with the idea of imposing a requirement
> on that group that requires them to pay for the tools.
> However, it is not just the US agencies doing this work. There are now 117
> cyber commands and there is a real problem of 'loose cyber-weapons'. It is
> to the interest of the US and to all the other cyber-commands that a norm
> is established that cyber weapons are secured end to end throughout their
> lifecyle and tools produced to enable that to be achieved.
> Such tools do not currently exist. However some key patent expiries that
> have occurred and will be complete in November this year make true end to
> end data level encryption practical. I have proof of concept but short of
> infringing code running in the lab which I will push out as soon as I can
> together with the supporting specifications.
> On Thu, Mar 9, 2017 at 4:02 PM, John C Klensin <> wrote:
>> Jari,
>> Let me suggest one addition to your list (with which I otherwise
>> agree):
>> 5. No matter how strong the in-transit encryption or other
>> measures, they doesn't mean much if the relevant endpoint hosts,
>> or intermediate hosts that have the traffic in the clear, can be
>> compromised.  We all know that, but we seem to sometimes need
>> reminding.   In particular, while it is definitely not an
>> argument against link encryption, we need to be cautious that we
>> are not protecting things in a way that inadvertently shifts the
>> points of vunerability from one place to another (especially
>> another that is either more easily compromised or that
>> constitutes larger and more concentrated single point of
>> failure) and then assume that it makes things more secure
>> overall.
>> best,
>>     john
>> --On Thursday, March 9, 2017 22:36 +0200 Jari Arkko
>> <> wrote:
>>> Up-leveling a bit from the discussion of best practices for
>>> surveillance organisations and virus builders (who apparently
>>> are partly the same crowd). We can make some more general
>>> observations, I think, maybe a bit more relevant for the rest
>>> of us.
>>> I don't think the reported findings are particularly
>>> surprising. But they seem to support what I think we knew
>>> already:
>>> 1. Security isn't a single feature, but needs to be thought
>>> in terms of the whole. Comms security and devices and ...
>>> 2. There is no such thing as privileged access to the good
>>> guys. It will leak / break / be shared.
>>> 3. Secretly held vulnerabilities make us all less safe.
>>> 4. The security of our communications and applications matters
>>> a lot. Lives are at stake, not just your browsing history.
>>> Jari