Subject: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Sep 2013 16:54:50 +1200

I got my arm slightly twisted to produce the attached: a simple
concatenation of some of the actionable suggestions made in the
discussion of PRISM and Bruce Schneier's call for action.

   Brian

-------- Original Message --------
Subject: I-D Action: draft-carpenter-prismatic-reflections-00.txt
Date: Thu, 19 Sep 2013 21:47:18 -0700
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Prismatic Reflections
	Author(s)       : Brian Carpenter
	Filename        : draft-carpenter-prismatic-reflections-00.txt
	Pages           : 9
	Date            : 2013-09-19

Abstract:
   Recent public disclosure of allegedly pervasive surveillance of
   Internet traffic has led to calls for action by the IETF.  This draft
   exists solely to collect together a number of possible actions that
   were mentioned in a vigorous discussion on the IETF mailing list.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-carpenter-prismatic-reflections

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-carpenter-prismatic-reflections-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Sep 2013 08:16:10 +0100

On 20 Sep 2013, at 05:54, Brian E Carpenter <[email-masked]> wrote:

> I got my arm slightly twisted to produce the attached:

Thanks for getting that done 
S

---

From: Josh Howlett <[email-masked]>
Date: Fri, 20 Sep 2013 09:59:02 +0000

I confess that I am confused by much of this discussion. As I understand
it, PRISM is not a signals intelligence activity; it only addresses that
data at rest within those organisations who have partnered with the NSA.
As such, improving protocol security will achieve nothing against PRISM;
it is a socio-political issue that is outside of the scope of a technical
standards organisation.

As such the only practical way for a typical user to protect themselves
against PRISM is to switch to other providers based in jurisdictions that
provide the appropriate protections, or agitate to change the applicable
laws within their own jurisdiction, where appropriate.

This is not, of course, an argument not to improve the security of our
protocols for other reasons, but let's please motivate this work
correctly. It will yield a greater probability of success.

Josh.

>discussion of PRISM and Bruce Schneier's call for action.

Janet(UK) is a trading name of Jisc Collections and Janet Limited, a 
not-for-profit company which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 20 Sep 2013 20:16:14 +0900

Josh Howlett wrote:

> I confess that I am confused by much of this discussion.

Several people in IETF is under control of NSA, maybe.

> As I understand

Right.

> laws within their own jurisdiction, where appropriate.

Not necessarily.

The proper protection is to avoid cloud services and have our
own end systems fully under control of ourselves.

Toward the goal, IETF should shutdown all the cloud related
WGs and never develop any protocol to promote cloud service.

> correctly. It will yield a greater probability of success.

Using DH could protect us, until USG start deploying active attack.

So, it is important to develop technologies to detect attacks
against DH.

						Masataka Ohta

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Sep 2013 12:28:31 +0100

> correctly. It will yield a greater probability of success.

Brian I think nicely summarised the discussion that happened.

The way I think of it is that PRISM is just one label that's
being used to reflect the whole set of recent disclosures and
ensuing discussions. Phill has also talked about PRISMproofing
which seemed to resonate with some people. I've started using
the term Snowdonia for all this stuff, but we really shouldn't
get hung up on the labels since that's all they are.

As you say, what we need to do in the IETF is figure out what
we should be doing about it all, and then go do that. That is
a work in progress and will undoubtedly be for a while to
come, but folks are working at it, which is good.

S.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 20 Sep 2013 15:15:04 +0300

Josh, Stephen,

It is important to understand the limitations of technology in this discussion. We can improve communications security, and in some cases reduce the amount information communicated. But we cannot help a situation where you are communicating with a party that you cannot entirely trust with technology alone. That does not mean we should not do anything. 

I would also like to focus this topic on the general implications for Internet technology, rather than any specific alleged activities. The discussion has heightened our need to consider the large-scale monitoring threat. It is important to understand that the overall situation is probably bigger and more complex than we see today, and it will also evolve as time goes by. Hence: if we build something, lets build for the general case, reducing ability of outsiders to get into communications, reduce amount of sensitive information transported, make privacy attacks more costly, etc.

Jari

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 20 Sep 2013 22:06:20 +0900

(2013/09/20 21:15), Jari Arkko wrote:
> Josh, Stephen,
> 
> It is important to understand the limitations of technology in this
> discussion. We can improve communications security, and in some
> cases reduce the amount information communicated. But we cannot
> help a situation where you are communicating with a party that
> you cannot entirely trust with technology alone.

We can discourage people communicating with a party that are
under full control of USG, which is why using cloud services
should be discouraged, which is a technical issue.

						Masataka Ohta

---

From: Scott Brim <[email-masked]>
Date: Fri, 20 Sep 2013 09:36:52 -0400

> I would also like to focus this topic on the general implications for Internet technology, rather than any specific alleged activities. The discussion has heightened our need to consider the large-…

Yes.  I'm really pleased that privacy in communications has come to
the fore and that we're trying to design it in, but there is much more
to it than the issue of general surveillance.

Scott

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 20 Sep 2013 19:56:37 +0300

Hi Masataka,

> should be discouraged, which is a technical issue.

An open standardization process means that everyone can participate,
including people who work for the government (directly or indirectly).
Whether you like what someone is putting forward is a completely
different story but I hope you would at least look at the content before
judging it.

So, I believe this attitude against people and companies who may have
had, or still have relationships with governments is counterproductive.

On your argument against cloud standardization in the IETF I have two
remarks, namely :

* Cloud services (with whatever definition you use) indeed presents
challenges for privacy and security.

* There is no standardization in the IETF on something like the "cloud".
On the other hand  I have to say that almost every protocol we
standardize in the IETF could be used in a cloud service. For example,
many cloud services use HTTP. Should we stop working on HTTP?

Ciao
Hannes

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 21 Sep 2013 06:08:21 +0900

> including people who work for the government (directly or indirectly).

As long as a standard being developed is within the scope of
the process, yes.

> different story but I hope you would at least look at the content before

Developing protocols to promote antisocial activities is worse
than developing Ethernet/Wifi protocol in IETF.

> had, or still have relationships with governments is counterproductive.

Protection from governments is not very productive, indeed, which
does not mean we shouldn't do it.

> many cloud services use HTTP. Should we stop working on HTTP?

For example, the following RFC:

	6208 	Cloud Data Management Interface (CDMI) Media Types
	K. Sankar, A. Jones [ April 2011 ] (TXT = 23187) (Status:
	INFORMATIONAL) (Stream: IETF, WG: NON WORKING GROUP)

is a product of IETF to promote cloud service.

						Masataka Ohta

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 21 Sep 2013 09:03:57 +1000

> WGs and never develop any protocol to promote cloud service.

I draw the opposite conclusion, actually. With good standards, we can encourage a larger number of services to exist, raising the cost of monitoring them all.

The problem is that the data is all concentrated in a small number of places, making it too easy to collect. 

To wit, right now Dropbox has a stranglehold on the personal data sync market; if I try to run my own server, or use an alternative service, I lose a significant number of benefits. 

I should be able to choose my own data sync server, whether it's one I run, or one run by my paranoid friend, or by a local company, or a US company that's in bed with the NSA. Good standards allow that to happen.

Sticking our collective heads in the sand and saying "cloud isn't happening" isn't going to change anything.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 21 Sep 2013 10:33:46 +0900

Mark Nottingham wrote:

> I draw the opposite conclusion, actually. With good standards,
> we can encourage a larger number of services to exist,
> raising the cost of monitoring them all.

Cost for monitoring should be large?

Then, protocols not have any authoritative specification and
should never be standardized and there should be no central
authority to manage different versions of the protocols.

> I should be able to choose my own data sync server, whether
> it's one I run, or one run by my paranoid friend, or by a
> local company, or a US company that's in bed with the NSA.

The only secure way is to run your own.

> Good standards allow that to happen.

I'm afraid you want to increase monitoring cost.

						Masataka Ohta

---

From: SM <[email-masked]>
Date: Fri, 20 Sep 2013 22:02:08 -0700

Hi Brian,
>discussion of PRISM and Bruce Schneier's call for action.

Thanks for writing the draft.  For the sake of disclosure [1], I know 
some of the XSF members.

draft-carpenter-prismatic-reflections-00 mentions that:

   "Clearly, we have a lot of specification work ongoing in different
    areas that helps to mitigate various security vulnerabilities.
    This ranges from recent work on XMPP end-to-end security ...."

I recently read an article about XMPP ( 
https://www.eff.org/deeplinks/2013/05/google-abandons-open-standards-instant-messaging 
).  From the article:

   "removes the option to disable the archiving of all chat communications"

Regards,
-sm

1. I welcome any questions about conflict of interest.

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 21 Sep 2013 15:48:22 +1000

> authority to manage different versions of the protocols.

From a PRISM viewpoint, the cost of parsing different formats, understanding different wire protocols, etc. is trivial. The real cost is negotiating with / bullying each provider into giving access. Especially if it's not hosted or doing business in a country you control.

> The only secure way is to run your own.

That's a very simplistic definition of "secure."

---

From: Roger Jørgensen <[email-masked]>
Date: Sat, 21 Sep 2013 15:42:46 +0200

> discussion of PRISM and Bruce Schneier's call for action.

There are one thing I don't see mention in your draft, the discussion
that moved from ietf@ and over into lisp@ about encryption by default
wherever it's possible. It's one concrete action this
NSA/Snowden/Bruce thing has started.

-- 

Roger Jorgensen           | ROJO9-RIPE
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 21 Sep 2013 18:24:24 +0100

> NSA/Snowden/Bruce thing has started.

FWIW, I'm also maintaining a list of concrete proposals and
relevant I-Ds that I've seen. [1] I've not noticed an I-D on
the LISP idea though but let me know if there's one I missed.

S.

[1] http://down.dsg.cs.tcd.ie/misc/perpass.txt

---

From: Roger Jørgensen <[email-masked]>
Date: Sat, 21 Sep 2013 19:45:59 +0200

> On 09/21/2013 02:42 PM, Roger Jørgensen wrote:
<snip>
> the LISP idea though but let me know if there's one I missed.

are no new I-Ds yet no.. :(

--

---

From: Paul Wouters <[email-masked]>
Date: Sat, 21 Sep 2013 21:47:11 -0400 (EDT)

> the LISP idea though but let me know if there's one I missed.

It's a draft from 1998:

http://tools.ietf.org/html/draft-ietf-ipsec-internet-key-00

I'm considering implementing something like that for the next version of
libreswan. But if we resurrect this draft, it needs work to get modernized
or be started as a complete rewrite from scratch. For exaple, we'd have
to ensure that these connections remain sandboxed to the machine, and
that any IP assignments are not leaking outside the machine (in the
light of NAT based inner IPs, etc)

Paul

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 22 Sep 2013 12:08:29 +0900

Mark Nottingham wrote:

> From a PRISM viewpoint, the cost of parsing different formats,
> understanding different wire protocols, etc. is trivial.

That is a reasoning to deny the point of you:

: I draw the opposite conclusion, actually. With good standards,
; we can encourage a larger number of services to exist,
: raising the cost of monitoring them all.

So, denying the point, you agree with me.

Note that "the number of services" != "the number of service
providers".

> The real cost is negotiating with / bullying each provider into
> giving access. Especially if it's not hosted or doing business
> in a country you control.

If only the number of cloud providers were large.

However, as there is some scale merit, there is a tendency that
the number of the providers will be small and all of the providers
naturally have considerable amount of hardware at the central part
of the Internet, that is, in US, which means the providers are
subject to USG control.

And, USG is not the only government we should be protected from.

> That's a very simplistic definition of "secure."

See above how simplistic your view is against so complex
nature of PRISM etc, against which, only the simplest
protection is effective.

						Masataka Ohta

---

From: Christian Huitema <[email-masked]>
Date: Sun, 22 Sep 2013 04:32:50 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Thursday, September 19, 2013 9:55 PM
To: IETF discussion list
Subject: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]

   Brian

-------- Original Message --------
Subject: I-D Action: draft-carpenter-prismatic-reflections-00.txt
Date: Thu, 19 Sep 2013 21:47:18 -0700
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

Abstract:

---

From: Christian Huitema <[email-masked]>
Date: Sun, 22 Sep 2013 04:40:47 +0000

> discussion of PRISM and Bruce Schneier's call for action.

Brian,

This is a useful summary, but I would like to see a few additions:

1) Encourage protocol designs that rely on peer-to-peer transmission, rather than intermediate relays, because relays are natural targets for interception services.

2) Encourage distributed services over centralized services. For example, social networking services today are heavily centralized. A distributed architecture would allow distribution of data at multiple location, managed by different commercial companies and covered by different legal authorities.

3) Require security sections of new RFC to include "mass surveillance" in their threat model and consider mitigations.

-- Christian Huitema

---

From: Dave Crocker <[email-masked]>
Date: Sat, 21 Sep 2013 21:49:00 -0700

On 9/21/2013 9:40 PM, Christian Huitema wrote:
> 1) Encourage protocol designs that rely on peer-to-peer transmission,
> rather than intermediate relays, because relays are natural targets
> for interception services.

Unless you are interacting on the same local net segment, when is
Internet communications not through a relay?  Router, MTA, Web cache,
whatever.

Given that, ultimately, there are always routers, what is the realistic 
improvement you are suggesting?

> 2) Encourage distributed services over centralized services. For
> example, social networking services today are heavily centralized.

+1

Except that essentially all services other than email have gained 
popularity in centralized form, including IM.  So there appear to be 
some important and difficult operational and usability barriers, 
standing in the way of more truly distributed applications.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 22 Sep 2013 18:06:00 +1000

> So, denying the point, you agree with me.

I'm really not sure what you're getting at here, but I suspect we're not going to convince each other. That's OK with me.

Regards,

---

From: Paul Wouters <[email-masked]>
Date: Sun, 22 Sep 2013 12:59:02 -0400 (EDT)

On Sat, 21 Sep 2013, Dave Crocker wrote:

> Except that essentially all services other than email have gained popularity 
> in centralized form, including IM.

Note that decentralising makes you less anonymous. If everyone runs
their own jabber service with TLS and OTR, you are less anonymous than
today. So "decentralising" is not a solution on its own for meta-data
tracking.

> So there appear to be some important and 
> difficult operational and usability barriers, standing in the way of more 
> truly distributed applications.

Because people still think of data centers are the CPUs running the
internet, when they should be thinking of loading up everyone's phones
with these services. These devices are more powerful that our 4U servers
of 10 years ago.

Paul

---

From: John C Klensin <[email-masked]>
Date: Sun, 22 Sep 2013 17:07:28 -0400

--On Sunday, 22 September, 2013 12:59 -0400 Paul Wouters
<[email-masked]> wrote:

>> Except that essentially all services other than email have
>> gained popularity  in centralized form, including IM.
> 

Perhaps more generally, there may be tradeoffs between content
privacy and tracking who is talking with whom.  For the former,
decentralization is valuable because efforts to compromise the
endpoints and messages stored on them without leaving tracks is
harder.  In particular, if I run some node in a highly
distributed environment, a court order demanding content or logs
(or a call "asking" that I "cooperate") in disclosing data,
keys, etc., would be very difficult to keep secret from me (even
if it prevented me from telling my friends/ peers).   And a lot
more of those court orders or note would be required than in a
centralized environment.  On the other hand, as you point out,
traffic monitoring is lots easier if IP addresses identify
people or even small clusters of people.

The other interesting aspect of the problem is that, if we want
to get serious about distributing applications down to very
small scale, part of that effort is, I believe necessarily,
getting serious about IPv6 and avoidance of highly centralized
conversion and address translation functions.

    john

---

From: Josh Howlett <[email-masked]>
Date: Sun, 22 Sep 2013 21:39:43 +0000

Jari,

>discussion. We can improve communications security, and in some cases
>reduce the amount information communicated. But we cannot help a
>situation where you are communicating with a party that you cannot
>entirely trust with technology alone. That does not mean we should not do
>anything.

Right. My primary concern was that the most effective responses for these
issues are rather different (technical controls versus regulatory
controls). I understand that "PRISM" is being used as a convenient label
to describe a multitude of sins; but, this will only be obvious to those
that understand the issues. Given the level of interest in this topic
(e.g., the daily media circus), we should be honest in what we can
practically achieve at a protocol level.

>I would also like to focus this topic on the general implications for
>Internet technology, rather than any specific alleged activities. The
>discussion has heightened our need to consider the large-scale monitoring
>threat. It is important to understand that the overall situation is
>probably bigger and more complex than we see today, and it will also
>evolve as time goes by. Hence: if we build something, lets build for the
>general case, reducing ability of outsiders to get into communications,
>reduce amount of sensitive information transported, make privacy attacks
>more costly, etc.

That's all good stuff. That said, personally I would characterise this as
a problem of Internet governance, and so I rather hope that ISOC have
ambitions beyond releasing a press statement.

Josh.

---

From: Roger Jørgensen <[email-masked]>
Date: Mon, 23 Sep 2013 08:48:07 +0200

On Sun, Sep 22, 2013 at 6:59 PM, Paul Wouters <[email-masked]> wrote:
<snip>
> today. So "decentralising" is not a solution on its own for meta-data

When I'm talking about decentralizing of internet I'm talking more
about the traffic flow.

We are sort of already on the way there with CDN moving much used
content close to the user, Microsoft updates are done this way afaik,
youtube, think gmail are distributed to. I think this is mostly done
due to cost and user-experience reasons.

We should go further, end-users should be able to communicate with
each other in a direct fasion as possible, preferable not going
through central chokepoints at all. Why send a videosession between
two neighbours 3000km just because they have different ISP that don't
want to exchange local traffic local even they are in the same
physical room with their equipment? In a rack next to each other? That
is how internet in Norway are mostly done today with a very few
exceptions. That means more interconnect between ISPs, more IX'es, and
alot more distributed routing...

... but not sure if this is really in the IETF domain at all, is it a
technical, economical or political issues that preventing this today?

--

---

From: Ben Laurie <[email-masked]>
Date: Mon, 23 Sep 2013 12:07:49 +0100

On 21 September 2013 06:02, SM <[email-masked]> wrote:
> Thanks for writing the draft.  For the sake of disclosure [1], I know some
> of the XSF members.
>

What it removes is default disabling. It is still possible to disable
all archiving, you just have to do it for each chat.