Re: The CIA mentions us

Yoav Nir <> Tue, 14 March 2017 06:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 70B061293EC for <>; Mon, 13 Mar 2017 23:42:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id arotvrRkqusD for <>; Mon, 13 Mar 2017 23:42:11 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 21FB61289B0 for <>; Mon, 13 Mar 2017 23:42:11 -0700 (PDT)
Received: by with SMTP id n11so56071771wma.1 for <>; Mon, 13 Mar 2017 23:42:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=N04GFp19YA212dBKypHjG7rsLw62ujn+EwU4ejz1v8Y=; b=mIsJmfGV7XYWy8QrJxV2hbmc0aWtDRtxwK0++HaCt4AYBsgmBGQnmH5VS1HYRdmlrS WqWvg2rRF05bZSXeD+CAJ7Ko877MEMA4Bj3/xLyE5d8nibwGn0FU/RPrCuWM3UZCbkV7 BpdsIF1bBi/ZiWFz6j6vLWtkfhbvISOO7psEHUA/umClvyNRb76YXfmGoM+sw3g3E52A Xm1TCJs/ea7azuTYgo1NqWPDa5Q+4TKPmP17xBnZVvF/UEJjerQJsydvsCwzG2Zp4C9R hmMKyPR/gQz5+e+H9DbcjJaoa4gftpVvBu3JUQ4kowPU8IQWy4W454ug/oyc2pqkJt2V 8yfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=N04GFp19YA212dBKypHjG7rsLw62ujn+EwU4ejz1v8Y=; b=T1v0Zxu/vmmXjRAsFMaxpevd+uRxNd3buFkSWRvudS96ksHJuC4DnlKa6uhw3TBRuR Uex+PmuJJVP2TpXbyzOqhUPbZg1UJOkegykB/sjAKF9i/NwC1a2jX1FuDlBudt0MjasV vXBAw5SxVNJqjTq5oH0tEmFx6XI5G+mJTin/Pr9f8PQ7zCihz7gcCdwMSAnMCOzV3GCN 8xKkjUxSNokZJ1SfsXCfKsHaWVspPjktz5HIdaTZxkOGfW7nXqL1JMZuJ8JaL3ZqT33k Njk1a+UZIsACYoHRAfEZsohefko0aPj4pHE7O9hGF+KHtOc1BgS5dGyJxMeyrWC4Iptg wR8Q==
X-Gm-Message-State: AFeK/H3Slig0u7fIwQrE9y53bOeV+WeegYgiPEgrSLI8hI52951dXDbutmYsSgX0Up4IGg==
X-Received: by with SMTP id v65mr12534632wme.49.1489473729483; Mon, 13 Mar 2017 23:42:09 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id 36sm27816018wrk.57.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 23:42:08 -0700 (PDT)
From: Yoav Nir <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_1732CF29-8E01-4125-B3EC-1AB3C18085B7"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: The CIA mentions us
Date: Tue, 14 Mar 2017 08:42:03 +0200
In-Reply-To: <>
To: willi uebelherr <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Cc: IETF discussion <>
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: Tue, 14 Mar 2017 06:42:14 -0000

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.


> 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.