Re: The CIA mentions us

willi uebelherr <> Tue, 14 March 2017 17:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A56E312DDA6 for <>; Tue, 14 Mar 2017 10:52:00 -0700 (PDT)
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 w2Fzi4LQE_T0 for <>; Tue, 14 Mar 2017 10:51:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EF4F512DDA5 for <>; Tue, 14 Mar 2017 10:51:58 -0700 (PDT)
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 69D5B1A1B08 for <>; Tue, 14 Mar 2017 17:51:58 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=squak; t=1489513918; bh=ZIV4oYom9mpGEDGhRcswRjM5GJs32WfBiL2rS7HYo6s=; h=Subject:References:To:From:Date:In-Reply-To:From; b=RIUQppfuow+x6tTC6KLKh8UBkhO7pdR/pS8CPCyk2fJHV/8pzdG9owBQWgAjEIiBT HICIwg86QhjSdSg/IqNCqy3Yw1YuZrQC1HIEiI8jVL9owdIWZukl8kNsdamhlWnx75 Zr/mvJRJOPwzyYRT+SyUkl5VDnQ12mGU/Usu4WH8=
Received: from [] (localhost []) (Authenticated sender: willi.uebelherr) with ESMTPSA id 9209F1C0128
Subject: Re: The CIA mentions us
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: IETF discussion <>
From: willi uebelherr <>
Message-ID: <>
Date: Tue, 14 Mar 2017 14:51:35 -0300
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
X-Mailman-Version: 2.1.21
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Mar 2017 17:52:00 -0000

Dear Yoav,

i thank you very much for your answer. Maybe, in any time, i have to go 
deeper to understand all the details.

But, on the other sider side, i don't like to follow the breakdown of a 
process into parts and look only to this parts.

The same problem we have with the TOR nets or IP proxy servers for 
anonymisation. If you have access to all interconnection central points, 
you know, who communicate.

The IP header never can encrypt. The routers need the data. You can 
create high coded VPNs, but you have to connect to this.

The alternative for me is a strong net-topology in our 
telecommunication. This means, that every node is connected to his 
neighbors. Then we don't need central IXPs.

The base for that are our strong independent local networks in every 
community. And there, the people have all, what they need. And for 
dataexchange, we use the interconnection net, our InterNet.

The result is, that the most people can have her mailbox server (and all 
other server functionality) in her local network. Can connect directly 
in the net. Then it will be impossible for all this state institutions, 
to follow all this data flows. And because the people from the community 
organise her local network itself, they give this criminal institutions 
no access.

This existing telecommunication is strong organised to have on any point 
in any time the access to all dataflows. We need a system, where this 
possibility don't exist.

many thanks and greetings, willi

On 14/03/2017 03:42, Yoav Nir wrote:
> Hi, Willi
>> On 14 Mar 2017, at 6:58, willi uebelherr <> wrote:
>> Phillip, if you use B), you don't need A).
> Consider email. If you and I were to use PGP or S/Mime encryption nobody can read the content of our messages. However, without transport-layer (or IP-layer. I’m an IPsec guy) encryption between the gmail server and the <> server, anyone monitoring the traffic can know that I am sending you an email. Protecting SMTP with TLS makes the connection only expose that someone of gmail is sending a message to someone on <>.  And “someone on gmail” is close to being half the Internet. So you really still need A.
> Of course we are still vulnerable to Google or <> informing on us.  Maybe we need some (E) about trustworthy intermediaries.
>> And how do you want to prevent traffic analysis? In a telekcommunication system, where all actors are privat companies and act for the state institutions and with a star topology, you will never be able to prvent any form of traffic analysis.
>> Your writing is a little bit naive for me.
> Well, TLS 1.3 and IPsec have some anti-traffic analysis feature, but there is little evidence of anyone using this effectively.
> Yoav
>> greetings, willi
>> On 13/03/2017 20:13, Phillip Hallam-Baker wrote:
>>> I think this particular failure demonstrates the situation pretty well:
>>> A) Without transport encryption, every network link is a potential point of
>>> compromise via traffic analysis.
>>> B) Without end-to-end data level encryption, every non endpoint device,
>>> every hard drive or removable storage is a potential point of compromise
>>> C) Without end point security, the end points are a potential point of
>>> compromise.
>>> D) Without trustworthy personnel, you are vulnerable to an insider threat.
>>> The security controls you need depends on your information security assets
>>> and your security concerns.
>>> If you are a high level security target then you need A + B + C + D. They
>>> are not alternatives, they are all requirements. It is really completely
>>> unhelpful for people to suggest tackling these separable concerns
>>> separately is 'useless'.
>>> Just as I would not consider personnel or physical security at the same
>>> time as end point security, I do not want to consider data level security
>>> at the same time as end point.
>>> To get back to the CIA leak, that 'hole you can drive a truck through' did
>>> not actually exist when the AV package was connected to the Internet. What
>>> we are seeing here is not a set of vulnerabilities, it is a set of research
>>> notes being compiled by people searching for vulnerabilities that has
>>> subsequently been exfiltrated, filtered to remove the good stuff and
>>> dumped.
>>> If you do end point security right, you can really be a 'PITA' to the
>>> people trying to break these systems. So the idea that end point security
>>> is futile is utterly misguided. If you use default deny approaches, end
>>> point security can be very effective. But end point security really isn't
>>> in scope for IETF unless we were to get into protocols for attestation of
>>> trustworthy hardware or the like.
>>> The reason I keep coming back to the data level security issue is that
>>> 1) It is in scope for IETF. Data level security protects data at rest and
>>> in motion.
>>> 2) There have been recent expiries and are imminent pending expiries of key
>>> IPR that makes a solution much easier.
>>> 3) It is one of the things we can fix that has the greatest security payoff.