Subject: The CIA mentions us

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 7 Mar 2017 16:53:46 +0100

In the Vault7 leak (malware library of the CIA
<https://wikileaks.org/ciav7p1/>), there is a page giving advices to
malware authors: how to avoid leaving traces
<https://wikileaks.org/ciav7p1/cms/page_14587109.html>. Among very
good advices, it talks of the IETF:

DO use ITEF [sic] RFC compliant network protocols as a blending
layer. The actual data, which must be encrypted in transit across the
network, should be tunneled through a well known and standardized
protocol (e.g. HTTPS)

Custom protocols can stand-out to network analysts and IDS filters.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 7 Mar 2017 11:02:54 -0500

This is all really good advice. I think it should be published as an RFC.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 7 Mar 2017 11:10:32 -0500

On Tue, Mar 7, 2017 at 11:08 AM, Stephane Bortzmeyer <[email-masked]>
wrote:

> On Tue, Mar 07, 2017 at 11:02:54AM -0500,
>  Phillip Hallam-Baker <[email-masked]> wrote
>  a message of 54 lines which said:
>
> I suspect we may run into IPR problems. The CIA author did not read
> the Note Well.
>

​If it was an NSA author they certainly would have​

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 7 Mar 2017 17:08:40 +0100

---

From: joel jaeggli <[email-masked]>
Date: Tue, 7 Mar 2017 08:23:35 -0800

> I suspect we may run into IPR problems. The CIA author did not read
https://en.wikipedia.org/wiki/Copyright_status_of_work_by_the_U.S._government

---

From: Fernando Gont <[email-masked]>
Date: Tue, 7 Mar 2017 14:40:11 -0300

> https://en.wikipedia.org/wiki/Copyright_status_of_work_by_the_U.S._government

Well... one would still need to assess whether such work is official or
not. :-)  At times, intelligence agency's work is not official --
actually, officially, such work didn't happen. :-)

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: David Morris <[email-masked]>
Date: Tue, 7 Mar 2017 10:35:15 -0800 (PST)

> actually, officially, such work didn't happen. :-)

Yeah, leaked classified materials don't need a copyright for protection.
One can go to jail with out ever getting a chance to discuss copyright
status.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 7 Mar 2017 15:41:39 -0300

> One can go to jail with out ever getting a chance to discuss copyright

One should consider oneself lucky in that case ;-)

Cheers,

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Mar 2017 11:19:51 -0500

​OK just so people know. I am working on this with a well known co-author
and we have a totally serious purpose behind the humorous aspects.

One point is that this is material people developing apps should be reading
so as to develop counter-counter measures.

The bigger point is that these documents and the weaponized attacks should
have been protected by end-to-end encryption throughout their lifecycle,
including on the Web server. We are currently at a conference on building
international norms for cyber and would like to establish 'lock up your
weapons' as a norm.

Besides being a norm that benefits the community, it is a norm that would
benefit every one of the 117 national cyber commands that currently exist.

​

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Mar 2017 11:28:48 -0500

> One should consider oneself lucky in that case ;-)

​US law is rather interesting. Unlike UK law where it is not necessary to
'sign the official secrets act' to be covered by it, US civil law is rather
less severe.​ Military law is a different matter, active duty military can
be ordered to be careful with classified materials. Civil law requires
intention to transmit to an unauthorized party or carelessness amounting to
constructive intent.

The documents do include material that purports to be classified as secret.
As a result many people are unable to read it because they have security
clearances and can't comment.

There certainly isn't a need to be concerned about copyright status as the
documents purport to be government property which would put them in the
public domain if true.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 9 Mar 2017 22:36:07 +0200

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

---

From: John C Klensin <[email-masked]>
Date: Thu, 09 Mar 2017 16:02:34 -0500

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
<[email-masked]> 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.
> 
> 4. The security of our communications and applications matters
> a lot. Lives are at stake, not just your browsing history.
> 
> Jari
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Mar 2017 16:11:32 -0500

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.

---

From: Vinayak Hegde <[email-masked]>
Date: Fri, 10 Mar 2017 02:48:41 +0530

> security requirement is end to end.

Agreed. IETF typically looks mostly at data-in-transit[1]. However
taking a systems perspective we need to look at data-in-use[2] and
data-at-rest[3] as well. Other important aspects such as key-mgmt also
matter here but I am not sure how much of this falls under the purview
of the IETF.

-- Vinayak
1. https://en.wikipedia.org/wiki/Data_in_transit
2. https://en.wikipedia.org/wiki/Data_in_use
3. https://en.wikipedia.org/wiki/Data_at_rest

---

From: willi uebelherr <[email-masked]>
Date: Thu, 9 Mar 2017 21:28:53 -0300

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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 10 Mar 2017 09:27:07 -0500

Phillip Hallam-Baker <[email-masked]> wrote:
    > 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.

I'm not really sure I understand what it means to secure a cyber weapon.

You could be talking about keeping the source code in locked briefcases,
or you could be talking about some kind of snake-oil DRM on the binaries,
like the movie and game industries thinks they have "invented".  Or something
else completely.

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

Now here you seem to be talking about securing things in transit.

if I may air some of my griping: tcpdump has recently dealt with some hundred
potential vulnerabilities found by futzing.  I was interested to find a file
called "PCAP" in the Vault 7 archives, but it's not really released yet.

What's annoying is that there is money for attack tools, and there are
rewards for finding exploits, but not much for fixing bugs, and many serious
disincentives to good design in the first place.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Dave Cridland <[email-masked]>
Date: Fri, 10 Mar 2017 17:14:29 +0000

On 9 March 2017 at 16:28, Phillip Hallam-Baker <[email-masked]> wrote:
> US law is rather interesting. Unlike UK law where it is not necessary to
> less severe. Military law is a different matter, active duty military can be
> ordered to be careful with classified materials. Civil law requires

In the UK, you don't have to have "signed the Act" to be covered by it
since the 1989 Act, no.

You do, however, sign even now, but it's there to remove a particular
defence of "I didn't know this was classified [any more]", since one
signs to acknowledge that information seen might be classified and
that one understands that one shouldn't disclose them.

Of course this is delightfully off topic at this point.

Dave.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 10 Mar 2017 13:49:57 -0500

I do not mean either transport or snake oil.

DRM has been a bust because two problems were conflated

1) Limiting access to confidential documents to those with a need to know

2) Preventing disclosure but those granted access.

The first is a completely tractable problem of cryptographic engineering
that I have a working, almost open (November) solution for with MIT License
reference code.

The second is never going to have an absolute solution. Even with
trustworthy hardware, there are techniques that can break a device if you
are prepared to pay a lot of money to do so. Techniques that involve
electron microscopes and sanding down the back of devices. Even FIPS-140
level 3 are not absolutely immune.

But this disclosure would probably have been prevented with (1) alone and
almost certainly with (1) plus pervasive accountability controls. Which
incidentally, Mesh/Recrypt does support.

I want to establish an international norm that cyber commands secure their
attack code end to end and I am proposing an infrastructure that does
exactly that.

Now the utility of such a scheme embedded into Office, OfficeLibre and the
like would be vastly wider than just cyber commands. But one of the
pathologies of the US government research funding programs is that the only
work that can be funded is work that has a military application. So I am
framing the problem in this form for the benefit of DARPA program managers
looking to give me money to work on this.

I call my subset of the DRM problem Confidential Data Control. The
introduction of 'rights' into the problem statement is entirely spurious.

Right now, the crypto code works in Ed25519 and will probably work for
Ed448 by this evening. Getting it to work on Montgomery curves is a little
more complicated as I have to figure out how to do point addition as a
primitive separate from multiplication. If someone could shoot me some code
to copy, it would help me save a few hours and spend some quality time with
my daleks this evening.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 10 Mar 2017 22:13:28 +0200

FWIW, Stephen and I wrote a blog article around the
more high-level conclusions on this topic.

https://www.ietf.org/blog/2017/03/observations-on-the-cia-revelations/

Comments appreciated.

Jari

---

From: Ted Lemon <[email-masked]>
Date: Fri, 10 Mar 2017 16:46:46 -0500

The one thing I wish you'd mentioned in this blog, but did not, is a point someone made earlier on this thread: that the fact that the CIA needs to hack individual devices to bypass end-to-end encryption means that what we are doing in promoting encryption is effective and worth doing: rather than everybody's communications being vulnerable, individuals must now be targeted.

---

From: Bob Hinden <[email-masked]>
Date: Fri, 10 Mar 2017 14:53:06 -0800

Ted,

> On Mar 10, 2017, at 1:46 PM, Ted Lemon <[email-masked]> wrote:
> 

I think that’s a good point.

To expand what you said, these tools are for targeted attacks, not mass surveillance.  Encryption continues to be a strong protection against mass surveillance.

Bob

---

From: Jari Arkko <[email-masked]>
Date: Sat, 11 Mar 2017 01:48:08 +0200

It is a good point. Thanks. I’ll consider making a revision. Tomorrow.

Jari

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 11 Mar 2017 02:02:07 +0000

Hi Ted, Bob,

On 10/03/17 22:53, Bob Hinden wrote:
>> The one thing I wish you'd mentioned in this blog, but did not, is
>> a point someone made earlier on this thread: that the fact that the
>> CIA needs to hack individual devices to bypass end-to-end
>> encryption means that what we are doing in promoting encryption is
>> effective and worth doing: rather than everybody's communications
>> being vulnerable, individuals must now be targeted.
> 
> I think thatâ€™s a good point.
> 
> To expand what you said, these tools are for targeted attacks, not
> mass surveillance. 

I don't think your optimistic conclusion here follows, for two
reasons. Firstly, we've seen that the adversary here is not
driven by economic concerns and will attack not just a weakest
link, but all possible targets they can afford given their very
very large budgets. That I think means that these kinds of attacker
will attempt both pervasive and targeted attacks, and the fact
that they attempt the latter does not mean that the don't try
both. Secondly, it may be that different kinds of attacker have
different kinds of targets/goals and that some attackers here
(such as the claimed source of these materials) are generally
more interested in individuals and not in populations. So again,
without further information, the interest in targeted attacks
does not imply a technical or practical inability to mount
pervasive monitoring attacks.

And while I do think that the actions that many people in the
Internet community and in the IETF have taken have probably
made pervasive monitoring harder and/or more costly, I do not
think that's really that relevant to this particular leak. In
this case, I think the much more interesting thing is that
this is yet another demonstration that attack code that is
intended to be used for attacks (as opposed to demonstration)
is in the end hugely counter-productive. (And immoral too IMO,
but I'd not claim that we all need to agree with that last;-)

> Encryption continues to be a strong protection
> against mass surveillance.

I totally agree encryption is a major tool in our armoury.
But that's kind of orthogonal to issues arising from this
incident I think.

Cheers,
S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 10 Mar 2017 21:11:21 -0500

You also need to start off with

But Hilary's Emails!

---

From: joel jaeggli <[email-masked]>
Date: Fri, 10 Mar 2017 19:01:53 -0800

On 3/10/17 6:02 PM, Stephen Farrell wrote:
> both. 

Indiscriminately targeted attacks are clearly a persistent threat.
Attack tools that can leverage automation and large economies of scale
are part of the the basic oeuvre.  If your organization is large and
diffuse, the difference between indiscriminate attacks and targeted ones
may have no practical distinction .

> Secondly, it may be that different kinds of attacker have

low hanging fruit being what they are, if your goal is actually to
undermine the faith that efforts security focused tooling is actually
serving a useful purpose; then you seed leaks of your attack tooling or
someone else's because they're already  and sit back while your
adversaries have to ratchet up their own efforts.

---

From: Rich Kulawiec <[email-masked]>
Date: Sun, 12 Mar 2017 08:47:20 -0400

> 3. Secretly held vulnerabilities make us all less safe.

Two points:

A) Worth noting (h/t to Richard Forno):

	Rand: The Life and Times of Zero-Day Vulnerabilities and Their Exploits
	http://www.rand.org/pubs/research_reports/RR1751.html

The key findings are highly illuminating -- particularly the observation that
the median time -- the *median* time -- to develop an exploit for a zero-day
vulnerability is 22 days.

B) What one government knows, another will know soon.  There are enormous
resources available for this task and vulnerability information, unlike
some other forms of intelligence, can be immediately used with plausible
deniability and without attribution.

---rsk

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Mar 2017 11:01:57 -0400

On Mar 10, 2017, at 9:02 PM, Stephen Farrell <[email-masked]> wrote:
> very large budgets. [...]

> but I'd not claim that we all need to agree with that last;-)

True   OTOH, there's a good editorial in the NY Times recently that speaks to the points you've raised: https://www.nytimes.com/2017/03/09/opinion/the-truth-about-the-wikileaks-cia-cache.html <https://www.nytimes.com/2017/03/09/opinion/the-truth-about-the-wikileaks-cia-cache.html>

I think the main thing is that yes, of course, a state actor with unlimited resources can hack every hackable device indiscriminately.   But widespread encryption means that they have to do that.   And doing that is _much_ harder than intercepting passively, and more importantly, it's more detectable.   I am surprised that you find my response optimistic.   I feel pretty cynical about the situation.   I just believe that we have done some things that have improved matters, and that's worth mentioning.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 13 Mar 2017 19:13:11 -0400

I think this particular failure demonstrates the situation pretty well:
http://www.zdnet.com/article/leaked-us-military-files-exposed/

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.

---

From: willi uebelherr <[email-masked]>
Date: Tue, 14 Mar 2017 01:58:05 -0300

Phillip, if you use B), you don't need A).

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.

greetings, willi

---

From: Yoav Nir <[email-masked]>
Date: Tue, 14 Mar 2017 08:42:03 +0200

Hi, Willi

> On 14 Mar 2017, at 6:58, willi uebelherr <[email-masked]> wrote:
> 
> 

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 riseup.net <http://riseup.net/> 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 riseup.net <http://riseup.net/>.  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 riseup.net <http://riseup.net/> 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.
> 

Well, TLS 1.3 and IPsec have some anti-traffic analysis feature, but there is little evidence of anyone using this effectively.

Yoav

---

From: willi uebelherr <[email-masked]>
Date: Tue, 14 Mar 2017 14:51:35 -0300

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

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 14 Mar 2017 11:49:23 -0700

Phillip Hallam-Bakerwrote:
...
> 2) There have been recent expiries and are imminent pending expiries 
> of key IPR that makes a solution much easier.
> 
Clearly that statement is self-contradictory. If the IPR has existed long enough to be at expire, the 'easier solution' has existed for a long time. The choice of not using it is simply a cost issue. If people don't believe protecting the data is worth the cost, the data will be exposed.

> 3) It is one of the things we can fix that has the greatest security payoff.
You can "improve" it, but you will never "fix" it. As long as humans have to interact with the data, there has to be a mechanism to expose the data, and that mechanism will always be vulnerable to compromise.

Tony