Subject: Re: [perpass] Traffic analysis

From: "Joe St Sauver" <[email-masked]>
Date: Mon, 28 Oct 2013 10:49:45 -0700 (PDT)

Hi,

Stephen Farrell <[email-masked]>:

#Not quite sure, but I think we might get some benefit at the
#moment from considering how specific fields in real protocols
#undermine privacy (e.g. as Christian's draft does with the
#Received header fields in mail messages) even if/when TLS or
#other existing security mechanisms are properly used.

My concern is that many traffic analytic approaches tend to be 
exceedingly robust to "protocol improvements." Protocol tweaks 
may accomplish little when it comes to practically improving 
privacy if the underlying protocol's architecture and operational 
practice goes unchanged. 

For example, when it comes to email, shouldn't section 6 of
http://huitema.net/papers/draft-huitema-perpass-analthreat-00.txt
basically say, "if you want to avoid traffic analytic approaches
in the case of email, deploy and use Mixmaster anonymous remailers"? 
( https://en.wikipedia.org/wiki/Anonymous_remailers#Untraceable_remailers )

And if we *are* talking about that sort of approach, then I think
inevitably we also need to talk about how we simultaneously manage to
allow *wanted* private traffic while simultaneously preventing or 
managing *unwanted traffic* (e.g., spam). 

An awful lot of current anti-spam technology depends upon either 
reputation (which is obviously not present in the case of 
anonymous/non-attributable traffic), or content analysis (which 
is also obviously problematic, at least if we presume use of 
end-to-end encryption (at least until the content is decrypted 
on the end-user's device)).

I also think that if you're serious about email privacy, you 
really can't keep the discussion just at the level of sanitizing 
headers. You need to get into the format of the content that's
allowed as well. For example, it's well known that non-plain 
text email content (e.g., HTML-formatted email) is potentially a 
serious threat to privacy due to potential use of things like 
tracking gifs included in HTML-formatted email.

Regards,

Joe

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 28 Oct 2013 19:03:41 +0000

Hiya,

> exceedingly robust to "protocol improvements." Protocol tweaks 

Not all changes need be tweaks. Some might be though.

> For example, when it comes to email, 

To be honest, I don't see how we can "fix" mail myself so
that its not vulnerable to pervasive monitoring. I think
we can make such monitoring somewhat harder via better use
of TLS, and that's worth doing, but beyond that, I don't
see much that can be done without changes that I don't
think are likely to happen. I'd be delighted to be proven
wrong on that, so I'm happy to see it discussed but I'm
not hopeful.

Meanwhile, there are plenty of other protocols that are
also worth a look and might be more easily improved in
this respect, so even if mail isn't tractable, other things
may well be.

S.

> shouldn't section 6 of
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
> 
>

---

From: [email-masked]
Date: Mon, 28 Oct 2013 11:30:28 -0700 (PDT)

> ( https://en.wikipedia.org/wiki/Anonymous_remailers#Untraceable_remailers )

And good luck with that, at least on any kind of scale.

But your underlying point is very well taken: The section on email in this
draft focuses on irrelevancies and fails to take note of the real issues.

I hate to sound like a broken record, but folks really need to have some
familiarity with present-day email as it is actually deployed before making
these sorts of asssessments.

Again, present day email usage is increasingly concentrated to a fairly small
number of large ISPs and MSPs. (Small ISPs and enterprise setups are shifting
to using cloud services, and while the Snowden revelations may have slowed this
trend, they haven't stopped it.)

In regards to traffic analysis, this is in some ways a good thing. If the
connections from user clients to the ISP/MSP servers are secured at the
transport layer - and I have demonstrated that a lot of them are - then we
gain a lot by securing the streams between the large providers at the
transport level.

But the elephant in the corner is logging. Service providers maintain very
extensive logs of email traffic, if for no other reason than as a support
tool. These logs provide every possible detail needed for traffic analysis.

Of course one of the earliest Snowden revelations was that the NSA is
collecting these logs from US providers on a massive scale. And hopefully
everyone is aware of Smith v. Maryland, which essentialls says that metadata
is not constitutionally protected.

But before Eupopeans and others get all smug about this, speaking as someone
who has seen quite a few RFPs for mail systems, the only substantive difference
I see between the US and elsewhere is the US approaches this in a less
organized and systematic way and generally has fewer auditing and data
protection requirements. The data is still being collected, and most likely
shareed.

And as for practical and deployable measures that can be undertaken to address
this, I'm at something of a loss to suggest anything. Shifting back to a more
decentralized model sounds nice, but seems a bit outside the purview of a
standards process to try and make that happen.

And even if it a completely decentralized model was practical, in a
peer-to-peer world the metadata that would accrue from watching the connections
themselves would be a fair substitute.

As for mixed models, look at what happened to Lavabit.

> managing *unwanted traffic* (e.g., spam).

Yep. It's a daunting problem. And it is far from the only one.

> on the end-user's device)).

You basically have to push the content checks to the client. This has
not proven to be a terrific solution in practice.

> tracking gifs included in HTML-formatted email.

I think we can do a lot to make it harder to snoop on email content, although
ironically what we're likely to be able to accomplish under the "prism-proof"
rubric is unlikely to much of anything about the data collection the actual
Prism program performs.

But traffic analysis... unless the fact that those logs are likely to only be
accessible to state entities offers some consolation, I don't think there's
going to be much happiness here.

				Ned

---

From: "d.nix" <[email-masked]>
Date: Mon, 28 Oct 2013 13:42:13 -0700

Steven, (others),

> To be honest, I don't see how we can "fix" mail myself so that its
> not vulnerable to pervasive monitoring. I think we can make such
> monitoring somewhat harder via better use of TLS, and that's worth
> doing, but beyond that, I don't see much that can be done without
> changes that I don't think are likely to happen. I'd be delighted
> to be proven wrong on that, so I'm happy to see it discussed but
> I'm not hopeful.

Is it within the purview of this list to discuss alternatives to, or
replacements for email as we currently know it? Or would that better
be proposed / discussed elsewhere so at to not dilute the topic at hand?

I also believe email as we generally know it is vulnerable to traffic
analysis even if we can encrypt the contents; there's just too much
observable metadata. Currently it seems to my somewhat limited
understanding that some combination of anonymous remailer systems and
properly configured VPN tunnels (and/or Tor perhaps...) are really the
only effective way to obscure your email traffic paths with our
existing systems. Traffic timing analysis is still an issue unless you
have either cover traffic (noise) or introduce a latency (delay) or
both (ala Mixminion / Pynchons Gate).

For the majority of average users, that still leaves you at the mercy
of the remailer operator and the VPN provider, and there are many
possible points of failure in using a VPN even without a Mallory or
Eve behind the scenes subverting your traffic.

That said, I'd still like to see the effort made in making existing
email as resistant as possible by default. Anything less is is a
disservice to the security of the user in general.

Regards,

Dave Nix

- --

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 28 Oct 2013 21:01:38 +0000

Hiya,

On 10/28/2013 08:42 PM, d.nix wrote:
> Is it within the purview of this list to discuss alternatives to,
> or replacements for email as we currently know it?

We've not been strict on this list to date. (That's
a secondary thing to talk about in Vancouver - should
we be more strict/focused on this list?)

My take fwiw, is that some discussion of how such things
might or might not be more resistant to pervasive
monitoring is ok. Doing detailed design of a more privacy
friendly alternative to mail on this list would be pointless
though - when would you be finished? So, if someone has
such a proposal then writing it up as an I-D that's
handled as usual is the thing to do... as usual:-)

Cheers,
S.

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 28 Oct 2013 21:43:31 -0700

I just placed a new copy of my draft on line as:

http://huitema.net/papers/draft-huitema-perpass-trafficanalysis-00.txt

The name changes following feedback, and to avoid unnecessary distractions. Thanks to Linus Nordberg for check proofing the previous version. I tried to add a couple of paragraphs to reflect the comments received on this list and in private, e.g., discussion of IPv6 addresses, or discussion of input-output correlation attacks against VPN servers or web proxies.

I did not add a complete discussion of e-mail monitoring. I am concerned that such addition would greatly increase the size of a draft centered on IP headers. E-mail monitoring may well deserve its own draft...

- -- Christian Huitema

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 29 Oct 2013 10:13:28 -0400

The metrics below are useful in
analyzing the dynamics of the group.
It certainly gets a gold star for diversity.

For those considering ID definitions,
the one below is available for use.

perpassturbating: usually, a paranoid
person stroking their keyboard to send
message on perpass email list beating
up on NSA and offering some mitigating
scheme in an attempt to prevent traffic
analysis.

-t

	Posts
Stephen 	Farrell 	106
Phillip 	Hallam-Baker 	53
Stephen 	Kent 	40
Karl 	Malbrain 	36
Hannes 	Tschofenig 	27
Randy 	Bush 	20
Brian 	Trammell 	18
Paul 	Wouters 	17
Scott 	Brim 	16
Ben 	Laurie 	16
Yoav 	Nir 	16
Tony 	Rutkowski 	16
Dave 	Crocker 	15

	SM 	14
Mike 	Demmers 	13
ned 	perpass 	13
Bjoern 	Hoehrmann 	12
Dean 	Willis 	12

	DataPacRat 	11
Kathleen 	Moriarty 	11
Jim 	Fenton 	9
Christian 	Huitema 	9
Hosnieh 	Rafiee 	9
Mark 	Handley 	8
Leif 	Johansson 	8
Douglas 	Otis 	8
Patrick 	Pelletier 	8
Peter 	Saint-Andre 	8
Richard 	Shockey 	8
Richard 	Barnes 	7
John-Mark 	Gurney 	7
joel 	jaeggli 	7
Brian 	Carpenter 	6
Ted 	Hardie 	6
Eliot 	Lear 	6
Yakov 	Shafranovich 	6
Yaron 	Sheffer 	6
Noel 	Torres 	6
Nicholas 	Weaver 	6
Jon 	Peterson 	5
Warren 	Kumari 	5
bill 	manning 	5
Russ 	White 	5
Jacob 	Appelbaum 	4
Stephane 	Bortzmeyer 	4
Alissa 	Cooper 	4
Joseph 	Hall 	4
Russ 	Housley 	4
Cullen 	Jennings 	4
Ralf Skyper 	Kaiser 	4
Nick 	Mathewson 	4
Nick 	Thomas 	4
Carl 	Wallace 	4
Benoit 	Claise 	3
Avri 	Doria 	3
Peter 	Gutmann 	3
Cullen 	Jennings 	3
Lucy 	Lynch 	3
Brian 	Rosen 	3
Theodore 	Ts'o 	3
Leo 	Vegoda 	3
Moritz 	Bartl 	2
Norbert 	Bollow 	2
Tim 	Bray 	2
Jon 	Callas 	2
James 	Cloos 	2
Elwyn 	Davies 	2
Karl 	Dubost 	2
Paul 	Hoffman 	2
Olle E. 	Johansson 	2
Simon 	Josefsson 	2
Paul 	Kyzivat 	2
Watson 	Ladd 	2
Albert 	Lunde 	2
Nicolas 	Mailhot 	2
George 	Michaelson 	2
d 	nix 	2
Linus 	Nordberg 	2
Marc 	Petit-Huguenin 	2
Martin 	Rex 	2
Joe 	St Sauver 	2
Eitan 	Adler 	1
Jari 	Arkko 	1
Mark 	Atwood 	1
Paul 	Bakker 	1
Marc 	Blanchet 	1
Dickson, 	Brian 	1
Richard Guy 	Briggs 	1
Eric 	Burger 	1
Adam 	Caudill 	1
William 	Chan 	1
Spencer 	Dawkins 	1
Nick 	Doty 	1
Roy 	Fielding 	1
Oliver 	Gasser 	1
Tobias 	Gondrom 	1
Harry 	Halpin 	1
Ryan 	Hurst 	1
Benjamin 	Kaduk 	1
Poul-Henning 	Kamp 	1
Hadriel 	Kaplan 	1
Phil 	Karn 	1
Adam 	Langley 	1
Eggert, 	Lars 	1
David 	Lloyd-Jones 	1
karl 	m 	1
Nikos 	Mavrogiannopoulos 	1
Alexey 	Melnikov 	1
David 	Morris 	1
Vidya 	Narayanan 	1
Trevor 	Perrin 	1
Alfredo 	Pironti 	1
Marsh 	Ray 	1
Eric 	Rescorla 	1
Michael 	Richardson 	1
Dan 	Schlitt 	1
Ross 	Schulman 	1
IETF 	Secretariat 	1
David 	Singer 	1
Ross 	Snider 	1
Elijah 	Sparrow 	1
Rene 	Struik 	1
Eduardo A. 	SuÃrez 	1
Andrew 	Sullivan 	1
Martin 	Thomson 	1
Mark 	Townsley 	1
Andy 	Wilson 	1
Robin 	Wilton 	1
Dan 	Wing 	1
Xiaoyong 	Wu 	1
Dan 	York 	1

---

From: Dave Crocker <[email-masked]>
Date: Tue, 29 Oct 2013 07:34:46 -0700

> scheme in an attempt to prevent traffic

Gosh, Tony, that's so clever.

However I can't understand how I fit into the count, since I've tried to 
be careful to say nothing against NSA, explicitly or implicitly, since I 
consider it out of scope for this list.  And I think that's true of 
number of others you cite.

I thought the purpose of this list was technical discussion, not 
discussion of government agencies, per se.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 29 Oct 2013 11:13:08 -0400

Hi Dave,

Good point.  Hence the word "generally."  I obviously
don't fit that definition either...nor frankly do most others,
as the discussion has largely been focussed on technical
matters.  The definition was intended to apply to those on
the list who seem to get pleasure from the government if
not private sector surveillance bashing and are motivated
by it.  So apologies for the over reaching comedic definition.

The metrics are, however, themselves interesting, and
indicative of who shapes the discussions, who are
especially motivated. and the  surprisingly large number
of people participating.  With 131 people posting, the
views are diverse, and among those participating above
the norm, the platforms are interesting albeit mostly
well tread and unlikely to be pursued except in small
communities of users that have the motivation and
money to pursue them.

best,
--tony

---

From: Dave Crocker <[email-masked]>
Date: Tue, 29 Oct 2013 08:27:15 -0700

> Good point.  Hence the word "generally."  I obviously

Tony,

The word you used was 'usually'.  Either way it's wrong.  Your asserting 
paranoia as the basis for the comments is entirely inappropriate here, 
both for scope and justification.

And the topic of the NSA has not dominated the list, which makes 
'generally' or 'usually' statistically wrong, also.

As for 'shaping' the discussion, your simplistic model implies that a 
single, cogent posting doesn't affect the shape as much as raw number of 
postings, or that we haven't had such postings.  It doesn't take a human 
communications masters degree to know that that's wrong, too.  While 
knowing posting rate can be informative, it's not nearly as substantive 
as you've just asserted.

So as comedic attempts go, you should try to develop better material, 
but my personal request is that you please not here.  Invoking NSA here 
is mostly likely (or will 'usually') create distractions.

Surely that's not your intent?[*]

d/

[*]  That's what is called a rhetorical question.

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 29 Oct 2013 08:28:07 -0700

I find this offensive and juvenile. Let's stick to the topics that this mailing list was designed for.

Alissa

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 29 Oct 2013 09:46:10 -0600

> this mailing list was designed for.

Yes, please!!!

Peter

---

From: Brian Trammell <[email-masked]>
Date: Tue, 29 Oct 2013 16:48:32 +0100

Not a big fan of +1s. But sometimes there's nothing else to be said.

+1,

Brian

Alissa Cooper wrote:
> On Oct 29, 2013, at 7:13 AM, Tony Rutkowski<[email-masked]>  wrote:
>

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 29 Oct 2013 17:43:47 -0400

Ned makes a number of excellent points here and the real elephant in the
room is under what terms and conditions is the ongoing collection of
metadata about IP communications in any form actually needed and in fact
absolutely necessary. 

There are perfectly good reasons to collect this stuff.   Though the ongoing
concern of this list is clearly the Snowden revelations some of us actually
want that data to prevent and investigate real and legitimate fraud and
abuse within the communications systems, optimize network transport etc. 

First if you take a little stroll over to the IETF STIR problem statement
you will see that fraudulent voice communications is becoming a huge problem
for National Regulators and Law Enforcement.   In the US the failure of
Rural Calls to certain areas now requires the US carriers to maintain ever
larger CDR records in order to preserve the integrity of the PSTN itself.   

http://www.fcc.gov/document/fcc-acts-combat-call-completion-problems-rural-a
merica

Consumers are totally outraged by the violations of THEIR PRIVACY... the
right to be left alone... by malicious Robo Callers who ignore the various
Laws about Do Not Call lists etc.   E-Mail spam has not gone away by any
account but the need for logs and records to attempt to track criminal
activity is still required.  We want to hunt these people down and shut down
their operations.  

The issue is appropriate safeguards on those records and there is
essentially nothing the IETF can do about that.  

It is useful to talk about strengthening key length and understanding to
underlying archectural reasons no one really wants to deploy secure
communications. 

I totally agree with this statement. " I think there are small technical
changes around the edges that can help, but I really see the solutions for
the metadata problem as more political and social than technical.
Concentrating on making encryption really, really easy to use would go a lot
further at this time than messing with deep changes, because people are not
even using what is already available."

Though I would not have used Tony's precise language on a public mail.  I'm
afraid I agree with the underlying sentiment.   

There are more than one joke running around Washington DC about actually
wanting the NSA to keep the CDR records if they would actually use them to
stop robo calls and call spoofing.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Monday, October 28, 2013 2:30 PM
To: Joe St Sauver
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [perpass] Traffic analysis

> #Not quite sure, but I think we might get some benefit at the #moment 
> from considering how specific fields in real protocols #undermine 
> privacy (e.g. as Christian's draft does with the #Received header 
> fields in mail messages) even if/when TLS or #other existing security 
> mechanisms are properly used.

> exceedingly robust to "protocol improvements." Protocol tweaks may 
> accomplish little when it comes to practically improving privacy if 
> the underlying protocol's architecture and operational practice goes 
> unchanged.

> basically say, "if you want to avoid traffic analytic approaches in 
> the case of email, deploy and use Mixmaster anonymous remailers"?
> ( 
> https://en.wikipedia.org/wiki/Anonymous_remailers#Untraceable_remailer
> s )

Again, present day email usage is increasingly concentrated to a fairly
small number of large ISPs and MSPs. (Small ISPs and enterprise setups are
shifting to using cloud services, and while the Snowden revelations may have
slowed this trend, they haven't stopped it.)

But before Eupopeans and others get all smug about this, speaking as someone
who has seen quite a few RFPs for mail systems, the only substantive
difference I see between the US and elsewhere is the US approaches this in a
less organized and systematic way and generally has fewer auditing and data
protection requirements. The data is still being collected, and most likely
shareed.

And as for practical and deployable measures that can be undertaken to
address this, I'm at something of a loss to suggest anything. Shifting back
to a more decentralized model sounds nice, but seems a bit outside the
purview of a standards process to try and make that happen.

And even if it a completely decentralized model was practical, in a
peer-to-peer world the metadata that would accrue from watching the
connections themselves would be a fair substitute.

> anonymous/non-attributable traffic), or content analysis (which is 
> also obviously problematic, at least if we presume use of end-to-end 
> encryption (at least until the content is decrypted on the end-user's 
> device)).

You basically have to push the content checks to the client. This has not
proven to be a terrific solution in practice.

> I also think that if you're serious about email privacy, you really 
> can't keep the discussion just at the level of sanitizing headers. You 
> need to get into the format of the content that's allowed as well. For 
> example, it's well known that non-plain text email content (e.g., 
> HTML-formatted email) is potentially a serious threat to privacy due 
> to potential use of things like tracking gifs included in 
> HTML-formatted email.

I think we can do a lot to make it harder to snoop on email content,
although ironically what we're likely to be able to accomplish under the
"prism-proof"
rubric is unlikely to much of anything about the data collection the actual
Prism program performs.

But traffic analysis... unless the fact that those logs are likely to only
be accessible to state entities offers some consolation, I don't think
there's going to be much happiness here.

				Ned

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 29 Oct 2013 22:49:24 +0000

Hi Rich,

> metadata about IP communications in any form actually needed and in fact

To the extent I can parse that, it seems like blatant assertion.

> abuse within the communications systems, optimize network transport etc. 

Countering fraud is a real requirement, agreed. I don't accept
that that implies a requirement that pervasive monitoring be
possible. But there are trade-offs and we do need to consider
those carefully.

Optimising transport seems bogus though - can you provide a
reference or argument as to why you'd need to pervasively monitor
in a privacy unfriendly way to do that?

> larger CDR records in order to preserve the integrity of the PSTN itself.   

I think STIR is a red herring here. Adding STIR doesn't really affect
pervasive monitoring since the overwhelming majority of calls already
use valid phone numbers so STIR doesn't really add to the ability to
pervasively monitor.

Now if we had a mechanism that added a useful signature whilst
disguising the caller identity, that might be interesting. Or one
that used a public key previously used to verify a signature to
encrypt call setup. And STIR does offer longer term possibilities
for both of those.

So I don't see STIR as being "for" or "against" pervasive monitoring.
Same as for any authentication mechanism.

But yes, there are privacy issues related to STIR that do need to
be considered.

> activity is still required.  We want to hunt these people down and shut down

Yes, helping folks block robo-calls is a good. I don't think STIR
is meant to actually define how to hunt anyone down though:-)

I'm also not at all sure that logging all the ham is required to
help track spammers.

> the metadata problem as more political and social than technical.

There is a political angle sure. And that's not an IETF concern
since the politics seem to be very different in different places.
Basically, the same logic as is set out in RFC 2804 applies to
that I think.

However, I very much disagree that this is *only* political. If
whoever is your favorite authority can pervasively monitor everyone
then so can others that you don't like so much. And that's true for
all values of "authority", at least in principle and quite likely
in practice, at least at some scale. And if we can have such bad
actors, there's no reason why they need to be nation states at all.
Plain old criminals can play this game and will. I believe we do
have good technical reasons for wanting to counter pervasive
monitoring.

Having said all that, yes, I do agree that doing more than making
the crypto stuff easier/better is hard. Doesn't mean we shouldn't
try though, if we really want to do better on privacy.

Regards,
S.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 29 Oct 2013 18:25:38 -0700

Dear Stephen,

See comments inline. 
On Oct 29, 2013, at 3:49 PM, Stephen Farrell <[email-masked]> wrote:

>> (elided) ...some of us actually

A few distinctions might be useful.

Packet routing itself (assuming BCP38 is used) clarifies where a message originated based on the source IP address.  In the case of IPv4, this alone can defend a service from abuse. When dealing with encrypted traffic over IPv6, there is a much greater need to obtain validated identifiers of exchange initiators.  From a transport perspective, this might be a certificate (PKI or DANE) associated with that of the client. 

Reverse DNS will be ineffective at dealing with abuse emitted from compromised systems.  Most of these will employ privacy extensions which means caching offers little benefit.  There will also be high levels of DNS server timeouts with delays consuming port resources.  In addition, port exhaustion may not be noted in system logs.  All of this offers users a poor and unfriendly Internet experience.

Would having an ability to monitor source domains in conjunction with opaque content represent an unfriendly privacy exposure?

For example, say the domain "telco.com" is validated, but none of the phone numbers exchanged can be determined.  By knowing it is "telco.com" and not "abusive-telco.com", the receiving server can defend services without expending excessive port services or enduring delays waiting for DNS responses.

Being able to validate a domain as the source of the exchange can be mitigated by allowing indirection to occur as an immediate next hop.  While pervasive monitoring of all traffic to and from a service end point may give clues about intended recipients, underlying conversations are not exposed.  It is even conceivable next hops could represent a type of domain randomizer resulting from some type of domain decoding.  Something akin to BATV like proxy comes to mind.

Regards,
Douglas Otis

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 30 Oct 2013 07:48:06 -0400

Hi Rich,

One gets the feeling that there are a fair number
of people here who are basically humorless and
probably don't watch VEEP! C'est la vie.

One saving grace is that the folks here who are
attempting to make life more difficult for those
doing commercial and government analysis are
basically cataloging techniques for which counter
measures can be taken.  So in that sense, this
other wise offensive list that serves the IETF
poorly, does have value.

--tony

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 30 Oct 2013 11:36:00 -0400

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Tuesday, October 29, 2013 6:49 PM
To: Richard Shockey
Cc: [email-masked]
Subject: Re: [perpass] Traffic analysis

Hi Rich,

On 10/29/2013 09:43 PM, Richard Shockey wrote:
> 
> Ned makes a number of excellent points here and the real elephant in 
> the room is under what terms and conditions is the ongoing collection 
> of metadata about IP communications in any form actually needed and in 
> fact absolutely necessary.

> concern of this list is clearly the Snowden revelations some of us 
> actually want that data to prevent and investigate real and legitimate 
> fraud and abuse within the communications systems, optimize network
transport etc.

Countering fraud is a real requirement, agreed. I don't accept that that
implies a requirement that pervasive monitoring be possible. But there are
trade-offs and we do need to consider those carefully.

[RS> ] Of course, then please define what you mean by pervasive monitoring.
Is it just monitoring by nation state actors or are you including British
Telecom, ATT, Google, Yahoo and Amazon etal  into the mix. 

Optimising transport seems bogus though - can you provide a reference or
argument as to why you'd need to pervasively monitor in a privacy unfriendly
way to do that?
[RS> ] 
[RS> ] That is simple traffic engineering. This is friendly pervasive
monitoring. Any reasonable network operator wants to know where its IP
traffic is coming from and where it is going. That provides the essential
data to optimize Layer 1 links and all sorts of other stuff not to mention
the negotiation of transit peering agreements.  If I can see from the IP
packets an asynchronous volume of traffic coming from one particular AS then
my peering coordinator will have a friendly chat with their counterpart.
This has reared its ugly head is several well-known incidents specifically
involving CDN. The well-known one is the US Comcast vs Level 3 dispute
instantly comes to mind. 

The difference between pervasive surveillance and traffic management is ONE
Octet.   Deep Packet Inspection is a fact of life. How you plan or ridding
the planet of that petulance is beyond my feeble brain.  

> First if you take a little stroll over to the IETF STIR problem 
> statement you will see that fraudulent voice communications is becoming a
huge problem

I think STIR is a red herring here. Adding STIR doesn't really affect
pervasive monitoring since the overwhelming majority of calls already use
valid phone numbers so STIR doesn't really add to the ability to pervasively
monitor.

[RS> ] So long as the majority of traffic is still TDM/SS7 based but we are
rapidly moving down a path that will no longer be the case which is why the
STIR problem statement is actually very important and very relevant to this
discussion.   I want to know who is trying to contact me and from where. 

Now if we had a mechanism that added a useful signature whilst disguising
the caller identity, that might be interesting. 

[RS> ]  I still want to track and trace the traffic.  I'd want to see what
your suggestion looks like but annominity can be used as a shield for
something more nefarious.  My running assumption here is the "The needs of
many ( to be left alone) outweigh the needs of the few."  There are actually
moral dilemmas here that have to be considered in the larger context.  

Or one that used a public key previously used to verify a signature to
encrypt call setup. And STIR does offer longer term possibilities for both
of those.
[RS> ] 
[RS> ] Agreed. 

But yes, there are privacy issues related to STIR that do need to be
considered.

[RS> ] Who's privacy? The calling party or the called party.   This is my
point. Enabling privacy for one may violate the privacy of the other. Now we
are really blasting past Layer 8-10 Economic Political and Religious into
Layer 11 Philosophy.   I'm totally incompetent to make judgments on that
Layer.  

> Consumers are totally outraged by the violations of THEIR PRIVACY... 
> the right to be left alone... by malicious Robo Callers who ignore the
various
> activity is still required.  We want to hunt these people down and 
> shut down their operations.

Yes, helping folks block robo-calls is a good. I don't think STIR is meant
to actually define how to hunt anyone down though:-)

[RS> ] You might think that.. I couldn't possibly comment.  But it is a
valuable tool to validate trusted traffic from SIP UA to UA. So how do I
hunt down robo callers? I have the drones fueled and ready. My point is we
still need track and trace for perfectly valid reasons any consumer or
enterprise can understand.  STIR as you well know is no "silver bullet" it's
a tool. One of many. The problem is well understood.  I'll post to STIR
later further comments on other ideas such as Enhanced CNAM etc.  People who
really want to communicate to someone they have no prior relationship with
should have the tools available to fully identify themselves.   That is a
good thing.  We can do productive work there. 

I'm also not at all sure that logging all the ham is required to help track
spammers.

[RS> ] Ask the people who have been defrauded.  There are really two sides
to this which is my larger point.  

> It is useful to talk about strengthening key length and understanding 
> to underlying archectural reasons no one really wants to deploy secure 
> communications.
> 
> I totally agree with this statement. " I think there are small 
> technical changes around the edges that can help, but I really see the 
> solutions for the metadata problem as more political and social than
technical.

There is a political angle sure. And that's not an IETF concern since the
politics seem to be very different in different places.
Basically, the same logic as is set out in RFC 2804 applies to that I think.

RS>  2804 was a very appropriate statement but there is a underlying thread
here that is running counter to those principals.  

However, I very much disagree that this is *only* political. If whoever is
your favorite authority can pervasively monitor everyone then so can others
that you don't like so much. And that's true for all values of "authority",
at least in principle and quite likely in practice, at least at some scale.
And if we can have such bad actors, there's no reason why they need to be
nation states at all.
Plain old criminals can play this game and will. I believe we do have good
technical reasons for wanting to counter pervasive monitoring.

Having said all that, yes, I do agree that doing more than making the crypto
stuff easier/better is hard. Doesn't mean we shouldn't try though, if we
really want to do better on privacy.

RS> Then you need to define who's privacy you want to defend. 

Regards,
S.

> Concentrating on making encryption really, really easy to use would go 
> a lot further at this time than messing with deep changes, because 
> people are not even using what is already available."
> 
> There are more than one joke running around Washington DC about 
> actually wanting the NSA to keep the CDR records if they would 
> actually use them to stop robo calls and call spoofing.
> 
> 
> 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> But your underlying point is very well taken: The section on email in 
> this draft focuses on irrelevancies and fails to take note of the real
issues.
> 
> I hate to sound like a broken record, but folks really need to have 
> some familiarity with present-day email as it is actually deployed 
> before making these sorts of asssessments.
> 
> Again, present day email usage is increasingly concentrated to a 
> fairly small number of large ISPs and MSPs. (Small ISPs and enterprise 
> setups are shifting to using cloud services, and while the Snowden 
> revelations may have slowed this trend, they haven't stopped it.)
> 
> In regards to traffic analysis, this is in some ways a good thing. If 
> the connections from user clients to the ISP/MSP servers are secured 
> at the transport layer - and I have demonstrated that a lot of them 
> are - then we gain a lot by securing the streams between the large 
> providers at the transport level.
> 
> But the elephant in the corner is logging. Service providers maintain 
> very extensive logs of email traffic, if for no other reason than as a 
> support tool. These logs provide every possible detail needed for traffic
analysis.
> collecting these logs from US providers on a massive scale. And 
> hopefully everyone is aware of Smith v. Maryland, which essentialls 
> says that metadata is not constitutionally protected.
> 
> But before Eupopeans and others get all smug about this, speaking as 
> someone who has seen quite a few RFPs for mail systems, the only 
> substantive difference I see between the US and elsewhere is the US 
> approaches this in a less organized and systematic way and generally 
> has fewer auditing and data protection requirements. The data is still 
> being collected, and most likely shareed.
> 
> address this, I'm at something of a loss to suggest anything. Shifting 
> back to a more decentralized model sounds nice, but seems a bit 
> outside the purview of a standards process to try and make that happen.
> 
>> can't keep the discussion just at the level of sanitizing headers. 
>> You need to get into the format of the content that's allowed as 
>> well. For example, it's well known that non-plain text email content 
>> (e.g., HTML-formatted email) is potentially a serious threat to 
>> privacy due to potential use of things like tracking gifs included in 
>> HTML-formatted email.
> 
> although ironically what we're likely to be able to accomplish under 
> the "prism-proof"
> rubric is unlikely to much of anything about the data collection the 
> actual Prism program performs.
> 
> But traffic analysis... unless the fact that those logs are likely to 
> only be accessible to state entities offers some consolation, I don't 
> think there's going to be much happiness here.
> 
> 				Ned

---

From: Eliot Lear <[email-masked]>
Date: Wed, 30 Oct 2013 17:15:10 +0100

On this point, it's my turn to sound like a broken record:

> connections themselves would be a fair substitute.

This is another really important point.  I'm sure many of us had the
first reaction that all this stuff should be decentralized, which of
course leads to "let's all get to IPv6".  To the extent that consumers
are able to have a choice about this, it's quite possible that a
decentralized model using our existing protocol suite could *harm*
privacy as Ned mentioned above.  Beyond that, one has to ponder what
externalities are introduced by having yet more consumer code accessible
to the great wild world.  Ironically, this Saturday, November 2nd, will
be the 25th anniversary of the Morris Worm.[1] <#1>  The world has
improved since that time.  A few things to highlight along these lines. 
One of my favorite studies to cite is that of Stephan Frei who looked at
update rates and compared business models.[2] <#2>  It seems that now
even WordPress is doing this[3] <#3>, but we are certainly not there yet
with certain systems.  I'm thinking of code used in SCADA systems and
automobiles in particular.  There are sometimes tradeoffs between
privacy and cybersecurity.  Many are specifically*not* protocol
tradeoffs, but operational tradeoffs.  Aggregation of services probably
is a good thing for cybersecurity – that's probably a worthy research
topic, by the way.

There is plenty of room for investigation and review of all of this, but
coming back to Paul's earlier warning[4] <#4> that he forwarded, let's
be thorough before jumping to recommendations for broad IETF changes. 
And let's please understand what tradeoffs there are.

Eliot

[1] http://en.wikipedia.org/wiki/Morris_worm
[2] http://www.techzoom.net/publications/silent-updates/index.en
[3] http://wordpress.org/news/2013/10/basie/
[4] http://www.ietf.org/mail-archive/web/perpass/current/msg00654.html

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 31 Oct 2013 11:05:49 -0400

Hi Rich,

You've hit several nails on the head here as to
why the premises for the list are so flawed.

Privacy (as opposed to PPII) is a legal,
societal, and religious matter, yet it is never
defined, and assumed by the proponents of
the list as accepted as an absolute tenet.  So
what if one is not of that religious persuasion?
What if you don't want to pay the broad array
of significant real costs and elevated threats
to finance those religious beliefs?  for example,
there are no use cases of where any form of
pervasive monitoring has brought down a plane.

Similarly neither "pervasive" nor "monitoring"
nor the concatenation of the two are defined
or even explained.

All of this is highly context dependent - as you
and others have repeatedly pointed out, and even
Stephen admits - raising the specter of bad actors.
Gee, not much new there.  However, the group
seemed to have been spun up over good actors
doing serious jobs, not bad ones.  That's ironic.
In fact, the proffered use cases seem directed
at impeding good actors and potentially seriously
damaging good actor requirements.

This is one of the worst examples of IETF upper
layer excesses witnessed over many decades.
While it can be written off as a canard to keep
some religious persuasions happy, it does real
harm to the IETF's stature.  This stuff belongs on
K-street and other lobbying venues, not in a
serious technical body that needs to accommodate
a broad spectrum of perspectives and needs.

--tony

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 31 Oct 2013 16:17:20 +0100

Guys, have a look at the lovely privacy consideration document the IAB 
published not too long ago. It explains you how we see privacy (which is 
different to what other people consider under privacy). It turns out 
that is exactly the approach we have taken with security many years ago.

Just compare it with security and you will for sure understand that the 
decision making process about how to design a system isn't entirely 
without judgement about what threats you care about and what security 
solutions you are willing to put in place. Most of the decisions are 
about tradeoffs.

The same is true for privacy.

I don't like this "we cannot define it precisely and so we shouldn't do 
anything about it" attitude.

Just pushing responsibilities to other communities does not help make 
progress. For this reason I have written https://goo.gl/a35BY2, which 
explains in what areas challenges exist.

Ciao
Hannes

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 31 Oct 2013 11:45:17 -0400

Hi Hannes,

The issue is not that privacy cannot be defined
It is that the concept of privacy and its import
varies widely in different societies, legal systems,
and people.   So why would a broad-based technical
technical body even deal with the topic.

As to your ID and its premises, it isn't exactly
accurate.  What is today regarded as the Internet
was run on DOD infrastructure.  The DARPA
Director who signed off on its pursuit in the 70s
recently testified that he had sufficient concerns
about its security that he directed the NSA to
become involved.  Until the mid-90s, most of
the traffic was pervasively monitored by the USG
and contractors.  Nothing new there, early commercial
Internet providers in the 1990s mined the data for
network management and commercial sales purposes.
In a best-effort, connectionless infrastructure, pervasive
monitoring is not unimportant.

That same DARPA director in the 1990s lead teams
to deal with what was expected to be significant misuse
of the infrastructure and protocols as the technology
replaced traditional - much more tightly controlled
and "surveilled" telecommunication infrastructure.
The Cybercrime Convention and other legal instruments
and requirements were developed because pervasive
monitoring was essential.  The likelihood of terrorists
pulling off something like a 9/11 via the Internet
was the subject of serious concern in the late 90s.
All the European bombings after that, made pervasive
monitoring so important, the EU adopted its directive
for the capture and storage of all meta data.

I could go on, but if you're serious about network
security, might I suggest engagement with any of the
numerous NIST and other governmental efforts
occurring around the world.  It's not just the IETF,
and if religious security and K-street lobbying
become the IETF's forté, the organization is only
harming itself.

--tony

On 10/31/2013 11:17 AM, Hannes Tschofenig wrote:
> I don't like this "we cannot define it precisely and so we shouldn't 
> do anything about it" attitude.
>

---

From: Scott Brim <[email-masked]>
Date: Thu, 31 Oct 2013 12:15:09 -0400

> technical body even deal with the topic.

IMHO you're at the wrong level, and the concept of privacy as used here is
abstract enough to be universal. What varies among cultures is what's kept
private, and how it is kept private - the instantiation of the concept.

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 31 Oct 2013 12:35:56 -0400

Abstract enough to be universal?
That sure encompasses a universe
of things.  Seems like a perfect
definition of religious beliefs.

You also ignore other very significant
components like how much it costs,
the impact on performance and innovation,
and how individuals feel (or not) about
the matter.  If someone wants to opt for
zero or diminished privacy - even if that
turkey can be stuffed with some technical
capability - in exchange for other benefits,
they should have the choice.

Most global technical bodies eschew
this subject.

--tony

On 10/31/2013 12:15 PM, Scott Brim wrote:
> IMHO you're at the wrong level, and the concept of privacy as used 
> here is abstract enough to be universal. What varies among cultures is 
> what's kept private, and how it is kept private - the instantiation of 
> the concept.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 31 Oct 2013 09:53:37 -0700

On 10/31/2013 9:15 AM, Scott Brim wrote:
>
> IMHO you're at the wrong level, and the concept of privacy as used here
> is abstract enough to be universal. What varies among cultures is what's
> kept private, and how it is kept private - the instantiation of the concept.

Hmmm.  That sounds suspiciously like the difference between mechanism 
and policy, with the requirement in the IETF to be one of defining 
mechanisms, while leaving policies for their application to others, 
outside of the IETF.

No wonder this limitation of scope is being criticized so vigorously -- 
one might even say religiously.  After all, it's not as if we've used 
that distinction much in the past, or with any real success...

d/

---

From: "d.nix" <[email-masked]>
Date: Thu, 31 Oct 2013 09:55:27 -0700

> the matter.  If someone wants to opt for zero or diminished privacy
> - even if that turkey can be stuffed with some technical capability
> - in exchange for other benefits, they should have the choice.

Conversely, if someone desires the maximum possible privacy, they
should also have that choice. If the system by it's design prevents
that choice, then those users that desire that measure of privacy are
pushed out.

- --

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 31 Oct 2013 13:35:41 -0400

Not sure where the "someone demands the maximum"
paradigm gets us.

It generally comes down to three factors:

1. what is mandated by governments
2. what providers implement
3. what the marketplace chooses

By the way, the same emeritus DARPA
Director recently opined, if you are really
concerned about surveillance or security,
don't connect to a network.  It is why NIST
and new security ecosystem has largely
shifted to a risk management approach.

If the IETF wants to do something meaningful
here, generate some templates under SP800-53 R4,

--tony

---

From: Scott Brim <[email-masked]>
Date: Thu, 31 Oct 2013 14:18:04 -0400

> Not sure where the "someone demands the maximum"

It gets us to protocol and system design principles.

> 3. what the marketplace chooses

You left out: what is possible in the protocol system provided to the
implementors.  There are issues with protocols, new and old, that are being
looked at right now in order to improve the _possibility_ of privacy.  This
is something the IETF can be very good at: creating/guiding the scope over
which the three rather generalized "factors" you mention can range.

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 31 Oct 2013 14:46:21 -0400

Good.  This is not unlike the NIST SP800-53r4 approach
which is the foundational U.S. (and probably CCRA)
network security approach.

--tony

On 10/31/2013 2:18 PM, Scott Brim wrote:
> implementors.  There are issues with protocols, new and old, that are 
> being looked at right now in order to improve the _possibility_ of 
> privacy.  This is something the IETF can be very good at: 
> creating/guiding the scope over which the three rather generalized 
> "factors" you mention can range.