Subject: [perpass] Some personal thoughts on the impact of pervasive monitoring

From: Ted Hardie <[email-masked]>
Date: Sat, 19 Oct 2013 18:21:31 -0700

Like most folks involved in this list, I have a personal response to the
current situation and some thoughts on how it will impact my or our work in
the future.  Since I expect we will pretty short of mic time in Vancouver
for thoughts like these, I decided to write them out.

http://tools.ietf.org/html/draft-hardie-perpass-touchstone-00

is the result.  It's quite short but a quick summary is this:

Pervasive monitoring induces self-censoring which harms the Internet and
its users.  At the scale of the modern Internet, that means it harms
humanity.

We can and should change our approach to Internet engineering and system
design to deal with this.  There will be costs for that, but we should pay
them.

It helps me, personally, to focus on a single user when asking whether a
system or protocol is appropriate in the current environment.  The draft
lays out why.

regards,

Ted Hardie

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 19 Oct 2013 21:42:00 -0400

[offlist]

> its users.  At the scale of the modern Internet, that means it harms

People behave differently when they know they are being watched.

I am not responding to PRISM, I am responding to the arrest of Miranda
using anti-terrorism powers. Trying to scare me makes me conclude that we
need to drastically reduce their capabilities.

-- 
Website: http://hallambaker.com/

---

From: Eitan Adler <[email-masked]>
Date: Sat, 19 Oct 2013 22:04:06 -0400

On Sat, Oct 19, 2013 at 9:21 PM, Ted Hardie <[email-masked]> wrote:
> Pervasive monitoring induces self-censoring which harms the Internet and its
> users.  At the scale of the modern Internet, that means it harms humanity.
>

You may want to directly address the arguments made in the paper
"Tussle in Cyberspace: Defining Tomorrow’s Internet" by Clark et al.

-- 
Eitan Adler

---

From: Tim Bray <[email-masked]>
Date: Sat, 19 Oct 2013 20:19:44 -0700

Excellent piece!

On Sat, Oct 19, 2013 at 6:21 PM, Ted Hardie <[email-masked]> wrote:

> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
>
>

---

From: Yoav Nir <[email-masked]>
Date: Sun, 20 Oct 2013 08:47:14 +0000

On Oct 20, 2013, at 4:21 AM, Ted Hardie <[email-masked]<mailto:[email-masked]>> wrote:

Like most folks involved in this list, I have a personal response to the current situation and some thoughts on how it will impact my or our work in the future.  Since I expect we will pretty short of mic time in Vancouver for thoughts like these, I decided to write them out.

Pervasive monitoring induces self-censoring which harms the Internet and its users.  At the scale of the modern Internet, that means it harms humanity.

We can and should change our approach to Internet engineering and system design to deal with this.  There will be costs for that, but we should pay them.

It helps me, personally, to focus on a single user when asking whether a system or protocol is appropriate in the current environment.  The draft lays out why.

regards,

Ted Hardie

Hi, Ted

In your draft, you propose we ask ourselves a question about any protocol we design, and that question can be something like "Can a gay kid in Uganda use this safely?"

IMO nothing we do here can yield an unqualified "yes" answer to that question. Nothing here relates to public statements such as personal blogs or Internet Drafts. Those are obviously public and the authors are identified, and the state apparatus can read them just fine, regardless of how secure we make them.

So there are two kinds of communications that we would seek to protect. public statements made anonymously, and private statements made either person-to-person or within a small group. You can't avoid any kind of monitoring, pervasive or otherwise, without having both encryption and authentication. This is regardless of whether the encryption and authentication are with the communications peer or with an anonymizer. Encryption and authentication with a middlebox (such as using a web-based mail service with TLS) is not sufficient, as the privacy of the communications depends on both the trustworthiness of the intermediary and strength of the authentication that the intermediary performs. I think it would be naive to expect an intermediary providing a web service to resist the government. So we're left with mandatory mutual authentication.

And that's the issue. We (meaning the people who work on Internet infrastructure) have never been able to deploy an identity management system good enough that everyone will use it.

I am not familiar enough with Ugandan politics to know to what extent the anti-gay laws are enforced or investigated. Most European countries and US states had such laws for decades without the police ever expending any resources to catch the criminals. But from what I've read in Wikipedia, the human rights situation is pretty grim for gays. So although it's tempting to think that using a US-based service like GMail would be safe from the local government, I don't think that's good enough to merit an unqualified "yes" answer to your question. The thing about pervasive monitoring, is that even if it was set up to catch terrorists, once the system is in place, it's very tempting to use the collected information to fight crime.

If the Ugandan government has decided to investigate a specific person, they can big his phone, install spyware on his computer, and follow him around. They will find evidence. The best we can do is to make our protocols such that pervasive surveillance is impossible. We can only hope, that if surveillance resistance is made such that the US government has the resources to spy on 10,000 people while Uganda has the resources to spy on 9 people (based on the ratio of national budget expenditures), that the Ugandan government will not waste its precious 9 "slots" on tracking down homosexuals.

So while I don't think we can make any particular protocol safe for a suspect, we can make it so that the average person feels safe enough to risk private communications as long as they believe they are "under the radar".  Ideally, the steps to reach that goal would be enough to obscure the few who do use strong person-to-person authentication.

But even with strong person-to-person authentication, a gay Ugandan would still have to avoid discussing anything that is illegal in Uganda with people he's not familiar enough with, for fear they are government agents. There can be no online support group helping teenagers, and there can be no Internet dating sites. Nothing we do can make that happen.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Sun, 20 Oct 2013 09:28:11 +0000

regards,

Ted Hardie

Hi, Ted

Yoav

---

From: Tony Rutkowski <[email-masked]>
Date: Sun, 20 Oct 2013 08:39:49 -0400

Reality check.

That is assuming the "average person" or the providers
of services to such persons, cares enough to do anything.
If the past ten years have demonstrated anything, the
average person and provider do not care.  Indeed,
conversely, they will be concerned about cost,
performance, ease of use,  and attractive feature sets.

Only the non-average will care in the following order:
governments (mostly), companies communicating
sensitive information, criminals and terrorists, and
a few super-paranoid.

The latest traitor-theft incident has principally
accomplished: 1) a significant shift of resources
by almost all the other governments to scale up
their ability to do better pervasive surveillance,
2) the significant scaling of surveillance and
analysis vendors to sell into the expanding
government and commercial markets, 3) the
shift of criminals and terrorists to more secure
communication, and 4) a degree of largely self
serving flailing around for exploitation purposes
by politicians and lobbying groups.  Perpass falls
into the noise, except for generating new ideas
for the above actors.  It is called the law of
unintended consequences. :-)
-t

On 2013-10-20 5:28 AM, Yoav Nir wrote:
> So while I don't think we can make any particular protocol safe for a 
> suspect, we can make it so that the average person feels safe enough 
> to risk private communications as long as they believe they are "under 
> the radar".  Ideally, the steps to reach that goal would be enough to 
> obscure the few who do use strong person-to-person authentication.
>

---

From: Mike Demmers <[email-masked]>
Date: Sun, 20 Oct 2013 10:08:37 -0700

On Sat, 19 Oct 2013 18:21:31 -0700

> http://tools.ietf.org/html/draft-hardie-perpass-touchstone-00

Suggest change from:

   "Can a gay kid in Uganda use this safely?"

to

   "Can a gay kid in Uganda use this safely? Is its design flexible enough to be used in his circumstances? Is it easy enough to use that a non-technical user may be reasonably be expected to use it?"

I'd guess you intended this. I think it is important to spell it out explicitly.

-Mike

---

From: Theodore Ts'o <[email-masked]>
Date: Sun, 20 Oct 2013 13:20:06 -0400

> performance, ease of use,  and attractive feature sets.

As they say, past results is not necessarily indicative of future
performance.

There seem to be at least some evidence that "normal users" have
started to care more about their security --- or you could say that
there have been a greater number of people joining the ranks of the
"super-paranoid".  And Yahoo has announced they will start turning on
encryption by default starting early next year; some have speculated
that Yahoo may have been felt impact of the reporting that showed that
the NSA had collected twice as many address books from Yahoo Users as
from all of the other major services combined.

One interesting indicator of how much "the average person" will care
is how much pressure politicians feel from their constiuents when some
of the intelligence gathering reform bills start getting debated
before congress --- especially the bill from Senators Wyden and Udall.

> Perpass falls
> for the above actors.

People who feel this way certainly have no obligation to participate
in perpass.  :-)

					- Ted

---

From: Mike Demmers <[email-masked]>
Date: Sun, 20 Oct 2013 12:31:02 -0700

On Sat, 19 Oct 2013 22:04:06 -0400

> "Tussle in Cyberspace: Defining Tomorrow’s Internet" by Clark et al.

Yes.

That paper, located here:

http://groups.csail.mit.edu/ana/Publications/PubPDFs/Tussle%20in%20Cyberspace%20Defining%20Tomorrows%20Internet%202005's%20Internet.pdf

is excellent and directly relevant to the design of protocols. Written in 2005.

-md

---

From: Ted Hardie <[email-masked]>
Date: Sun, 20 Oct 2013 13:41:59 -0700

Hi Yoav,

Thanks for reading the draft; some comments in-line.

On Sun, Oct 20, 2013 at 1:47 AM, Yoav Nir <[email-masked]> wrote:

>
>  On Oct 20, 2013, at 4:21 AM, Ted Hardie <[email-masked]> wrote:
>
>   Like most folks involved in this list, I have a personal response to
> the current situation and some thoughts on how it will impact my or our
> work in the future.  Since I expect we will pretty short of mic time in
> Vancouver for thoughts like these, I decided to write them out.
>
>  In your draft, you propose we ask ourselves a question about any
> protocol we design, and that question can be something like "Can a gay kid
> in Uganda use this safely?"
>
>  IMO nothing we do here can yield an unqualified "yes" answer to that
> question. Nothing here relates to public statements such as personal blogs
> or Internet Drafts. Those are obviously public and the authors are
> identified, and the state apparatus can read them just fine, regardless of
> how secure we make them.
>
>
I think we agree that there can be no unqualified "yes"; even if the
protocol and application are secure, there is always the risk of the camera
looking over your shoulder.

But I want to point out something about blogs or similar public statements;
while some systems require real names, not all do.  It's quite possible to
have an online journal or blog that uses a pseudonym and it's actually
relatively easy for that to be an okay outlet for a gay kid worried about
pervasive surveillance.  If that kid connects to largeblogsite.example over
a TLS protected link, the metadata shows the connection, but not the
content.  If largeblogsite has blogs on knitting, agriculture, and custom
cars, there is no signal to those engaged in surveillance that the blogs of
interest are LGBT in nature.  The authentication of largeblogsite.example
within TLS to the user needs to be secure (pinned to a CA, for example, to
avoid MiTM proxies), but there are various ways of making this more trusted
(again, no way to avoid all risk; if the CA is compromised, most bets are
off).

This doesn't gainsay the main point about safety, but it shows how thinking
about a particular user or group of users may actually make the general
privacy considerations more concrete.

>  So there are two kinds of communications that we would seek to protect.
> public statements made anonymously, and private statements made either
> person-to-person or within a small group. You can't avoid any kind of
> monitoring, pervasive or otherwise, without having both encryption and
> authentication. This is regardless of whether the encryption and
> authentication are with the communications peer or with an anonymizer.
> Encryption and authentication with a middlebox (such as using a web-based
> mail service with TLS) is not sufficient, as the privacy of the
> communications depends on both the trustworthiness of the intermediary and
> strength of the authentication that the intermediary performs. I think it
> would be naive to expect an intermediary providing a web service to resist
> the government. So we're left with mandatory mutual authentication.
>
>
> I think this presumes that there is a single government and a single
potential response from a web service.  That may not be valid.  If it is,
and you don't trust a particular service provider,  then mutual
authentication doesn't actually do much for you.  You need confidentiality
among participants without the participation of the service provider.
There are ways to achieve that, but they are not common nor are they
currently deployed at scale.  That may change. That may help with the point
you raise below, that the use of some techniques is currently a signal to
deepen the level of surveillance on an individual; if they become common,
that signal is lost to those who wish to follow those trails.

 And that's the issue. We (meaning the people who work on Internet
> infrastructure) have never been able to deploy an identity management
> system good enough that everyone will use it.
>
>  I am not familiar enough with Ugandan politics to know to what extent
> the anti-gay laws are enforced or investigated. Most European countries and
> US states had such laws for decades without the police ever expending any
> resources to catch the criminals. But from what I've read in Wikipedia, the
> human rights situation is pretty grim for gays. So although it's tempting
> to think that using a US-based service like GMail would be safe from the
> local government, I don't think that's good enough to merit an unqualified
> "yes" answer to your question.
>

I agree that it may never be unqualified.  But we can make it stronger.

> The thing about pervasive monitoring, is that even if it was set up to
> catch terrorists, once the system is in place, it's very tempting to use
> the collected information to fight crime.
>
>  If the Ugandan government has decided to investigate a specific person,
> they can big his phone, install spyware on his computer, and follow him
> around. They will find evidence. The best we can do is to make our
> protocols such that pervasive surveillance is impossible. We can only hope,
> that if surveillance resistance is made such that the US government has the
> resources to spy on 10,000 people while Uganda has the resources to spy on
> 9 people (based on the ratio of national budget expenditures), that the
> Ugandan government will not waste its precious 9 "slots" on tracking down
> homosexuals.
>
> suspect, we can make it so that the average person feels safe enough to
> risk private communications as long as they believe they are "under the
> radar".  Ideally, the steps to reach that goal would be enough to obscure
> the few who do use strong person-to-person authentication.
>
>  But even with strong person-to-person authentication, a gay Ugandan
> would still have to avoid discussing anything that is illegal in Uganda
> with people he's not familiar enough with, for fear they are government
> agents.
>

But can she see the videos of the Trevor Project?  Can he read medical
resources about HIV?   Can we assure [email-masked] that
they are really in a chat session with [email-masked]?

All of those will help.

There can be no online support group helping teenagers, and there can be no
> Internet dating sites. Nothing we do can make that happen.
>
> I appreciate that you have thought so deeply about this particular user;
thank you.  I hope it convinces you that thinking through a specific user
case can help us make concrete the steps we need to take to make our
protocols and systems more usable in the light of pervasive surveillance.

thanks,

Ted

---

From: Ted Hardie <[email-masked]>
Date: Sun, 20 Oct 2013 13:44:50 -0700

> performance, ease of use,  and attractive feature sets.
I think we are increasingly aware of folks who do care; journalists, for
example, are pretty sensitized at the moment to these issues.

> into the noise,

I think you and I disagree pretty fundamentally on this topic.  I think our
work can be signal that rises above the noise.  It's up to us to determine
whether or not we'll spend our efforts boosting the signal or not.

Ted Hardie

> except for generating new ideas

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 20 Oct 2013 21:59:15 +0100

Hi Ted,

Thanks for the draft. As you might guess from earlier discussion
on here, I think the more-than-MTI approach espoused is maybe the
right one, if we can figure out how to state the requirement well.
Have you any ideas on that, or on how we could get towards a
situation where that gained consensus?

I've a similar question wrt how to "consider more carefully and
more consistently the effects of information leakage by DNS and
other infrastructure" - any ideas how an effort in that direction
could usefully be structured?

Ta,
S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 20 Oct 2013 17:16:25 -0400

> As they say, past results is not necessarily indicative of future

It occurred to me the other day that many security mechanisms suffer from
the same problem as a Ponzi scheme: Bernie Madoff's investment fund never
missed a payment till the day it collapsed and all the money was gone.

Which is why I don't like arguments based on probability because the
probability you will be paid in full in a Ponzi scheme is 100% right up to
the day that they close their doors at which point the probability drops to
0%.

There are ways round this problem however. What I am doing at the moment is
to look at measures of the work factor that take into account things like
the time the effort is required, the monetary costs, the personnel etc.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 20 Oct 2013 23:32:02 +0200

* Ted Hardie wrote:
>interest are LGBT in nature.

I was under the impression that TLS as currently deployed would still
let an attacker know roughly when and how many bytes are exchanged and
if the blogs are reasonably static and public that should be enough to
reconstruct which are being read, especially if you can capture repeat
visits (the knitting blog might feature small vector graphics with
knitting patterns, and the custom cars blog might have large photos,
so if the user downloads a lot, custom cars are much more likely).

(And in practise there are many more problems, like the blogs might be
on different hostnames and the DNS lookup gives you away, or they might
load resources from third-party hosts, so you can tell blogs that have
some video from a popular video site on them from those that have not,
simply from the client connecting to the video service after loading up
whatever blog they are interested in, and so on.)
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Ted Hardie <[email-masked]>
Date: Mon, 21 Oct 2013 07:08:21 -0700

> situation where that gained consensus?
I think the issue here is that "mandatory to implement" is theoretically
something testable by the IETF's process; mandatory to use is a condition
of the overall system and far less liable to the same testing.  "Default
on" might be testable.

I think, though, to get anywhere we'll need a combination of insistence at
the protocol stage, user education about the meaning of confidentiality and
data integrity, and plain old marketing.  When a user can evaluate a
statement like "safer messaging alternative" and the company providing it
can profit from that evaluation, we'll get traction.

> could usefully be structured?
Well, I think some of the other comments have explored this.  If you are
putting up a web site for blogs, providing a URL like
blogname.blogsite.example leaks data that blogsite.example/blogname does
not; providing both (for vanity or safety, but not both) is a better design
than forcing the leak.  A document that described the issues here may be
quite useful, though I suspect it needs a lot more marketing than the usual
RFC.     On a slightly more protocol-oriented note, David Conrad pointed
out years ago that once DNS data is secured by DNSSEC, you could deliver it
over confidential channels.  If the validation is done at the end user's
system (or within the application there), downloading the data from
anywhere you trust should work.

regards,

Ted

---

From: Ted Hardie <[email-masked]>
Date: Mon, 21 Oct 2013 07:16:51 -0700

> so if the user downloads a lot, custom cars are much more likely).
If the pattern of download is consistent and the passive surveillance
system is keyed to look for that pattern, you're right that this is a
risk.  You can mitigate it as a user by downloading from multiple sites at
the blog site--if you're looking at custom cars and support information and
knitting, you're not going to trigger the pattern (or not as easily).  A
site that knows its data may be sensitive can also vary the data to avoid
easy pattern matching; this might get easier with the deployment of HTTP
2.0, since multiple flows are multiplexed over a single TLS connection;
deliver different in-line ads for the same content and you get different
patterns.

> whatever blog they are interested in, and so on.)

Third party hosts are indeed a problem; it's no help if you avoid
name.blogsite.example in favor of blogsite.example/name if you then point
to a third party whose DNS name leaks.

regards,

Ted

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 22 Oct 2013 00:23:07 +0200

>deliver different in-line ads for the same content and you get different

Right, thanks for the confirmation. Is this an area where the IETF can
and should do more? As an example, should the HTTP/2.0 specification
discuss or an accompanying specification discuss protocol options that
could be useful in mitigating such attacks? Perhaps some kind of meta
document that discusses when adding automatically generated noise to
mitigate such attacks becomes abusive and harmful to the network? It
seems to me this would be a next attack point if suddenly "everything"
goes encrypted over the wire, but I am not sure what level of interest
there is in doing anything about it.

(Even with HTTP/1.1 there are many options to add some innocious noise
and randomness, a browser can decide to forget a cached resource and
fetch it again, or decide it is not going to prefetch a resource or do
it later than normally, and with HTTP/2.0 servers can do similar things
with server-push).
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 21 Oct 2013 23:25:59 -0700

> situation where that gained consensus?

Networking standards are promoted by consensus and by network effects. In
the absence of some forcing function, "fallback to clear text" gets promoted
by network effects, because it is de facto forced by the sites that don't
bother deploying the more secure options. The best way to break that is to
provide "air cover" for security, e.g. a text in the protocol description
RFC that says "nodes requiring a modicum of security SHOULD refuse to use
clear text connections."  That would effectively turn the tables.

Suppose for example that a large enough mail service starts to require TLS
for SMTP connections. Many sites who are accustomed to send mail in clear
text will initially protest when their mail gets bounced. But if the
standard says that yes, they have all right to do that, then the big site
has "air cover." "I am not breaking you, I am just following best practice."
At this point, you will see more and more sites opting to turn on TLS, and
pretty soon the network effects will work in favor of encryption.

Of course, to be practical, this requires that sites can easily get a
certificate of some kind, PKI or DANE, to actually use TLS...

-- Christian Huitema

---

From: [email-masked]
Date: Sat, 26 Oct 2013 07:48:59 -0700 (PDT)

> clear text connections."  That would effectively turn the tables.

Exactly! The only thing I would add is that "cover" should include a
clear presentation of the tradeoffs and consequences.

Unfortunately this is surprisingly hard to do well. It's much easier to start
throwing MUSTs around.

This also is effectively what happened in the IMAP case: Large sites like gmail
and Apple only deployed imaps, with the result that a fully standards-compliant
client actually won't work with their service!

> pretty soon the network effects will work in favor of encryption.

This, OTOH, is a little trickier. You first have to distinguish between
SMTP SUBMIT and SMTP relay. I haven't surveyed the former extensively,
but the odds are good it's in roughtly the same situation as IMAP.

The latter is a problem due to the need for every client to work with every
server, as opposed to saying "use a client with these capabilities if you want
to use our service". It's a very different dynamic. Moreover, lots of people
have tried to shift to SSL/TLS in this space and it has not worked well at all.

But this doesn't mean there's no way to make the transition. One possibility is
an SMTP extension to require SSL/TLS on a per-message basis. (A draft has
already been written and is being discussed.) Another one, which I like a lot
better, is to opportunistic SSL/TLS use plus latching. Chris Newman is
working on a draft on that.

And this is actually a case where often-derided "bilateral agreement" idea in
X.400 could go a long way. The distribution of email usage is such that an
agreement to require SSL/TLS between the top-tier MSPs and ISPs would protect a
significant percentage of traffic. And think of the incentive that would
represent to other providers.

> certificate of some kind, PKI or DANE, to actually use TLS...

Require? Not necessarily - see above. But it would definitely improve the
situation if this stuff were easier to deploy.

				Ned

---

From: Eliot Lear <[email-masked]>
Date: Sat, 26 Oct 2013 18:32:26 +0200

Hi Ned,

> client actually won't work with their service!

And maybe that's a good thing, by the way.  But my main point is that
the IAB is reviewing this exact topic at a workshop that will take place
in December on Internet Tecnology Adoption and Transition.  It's not the
first time it's been considered, mind you.  See RFC 5218 by Dave Thaler
and Bernard Aboba.

Eliot

---

From: Avri Doria <[email-masked]>
Date: Sun, 27 Oct 2013 10:43:23 -0400

Hi

>  "Can a gay kid in Uganda use this safely?"

(though Uganda can be substituted by many other place names.)

I can think of few better touchstones.  I have been working with some people in Uganda and elswhere and I think you hit the nail on the head.

There is a real problem with any privacy measure that singles out someone as using it in a country where they can bust down your door just because you made them curious.

avri

---

From: [email-masked]
Date: Tue, 29 Oct 2013 22:44:10 -0700 (PDT)

> And maybe that's a good thing, by the way.

Getting the right outcome is definitely a good thing. But let's not pretend
that luck wasn't a big factor.

> But my main point is that
> in December on Internet Tecnology Adoption and Transition.

Question: Has anyone been invited that has designed or directly overseen large
server deployments of any sort? It might be instructive to hear from someone
like that.

>  It's not the

Yep.

				Ned