Subject: [perpass] On the perfect passive adversary, men at the end, and configuration versus mechanism

From: Brian Trammell <[email-masked]>
Date: Sun, 18 Aug 2013 20:45:26 +0200

Greetings, all,

On the floor of my home directory, there are notes for a paper we never finished called "The Perfect Passive Adversary"; intended as a survey of the state of the network security and measurement literature and practice to explain what is possible if one assumes an adversary which can (1) observe every packet of every communication at every point within a network but (2) does not have access to the endpoints beyond the network interface (i.e. no keyloggers, and no bulk access to user data at a service provider) and (3) cannot influence packet forwarding. It grew to be rather too wide in scope and too paranoid in tone to have a realistic chance at publication, so we dropped it, which in retrospect seems a silly choice.

I would propose that we consider this as one of the threat models we address; the exercise I propose is to examine the protocols we're familiar with and think about (1) what's in the payload, (2) what can be inferred from identifying metadata (IP addresses and port numbers, application-layer addresses (email addresses, URLs, etc) (3) what can be inferred from non-identifying metadata (data volume and packet counts, interarrival times,  control information such as sequence numbers, and so on).

It looks like this conversation is already well underway on the email side of the house, which is good. :) What follows are some further musings on the limitations of this approach.

In general, increasing use of end-to-end transport encryption[1] mitigates the threat of eavesdropping by a man in the middle; indeed, threat models involving intermediate eavesdropping are at this point extremely well understood, and well defended against, barring problems with the crypto protocols that I'm not a good enough cryptographer to understand.  A perfect passive adversary generally won't even bother trying to break this link: it's too strong, a testament to the attention that's been paid to it over the decades. Such an adversary could look for unprotected side-channels (e.g., SSH keystroke timing attacks, static HTTPS content size/timing fingerprints), or could give up on payload altogether and attempt to make inferences just from the flow keys (this being the point of large-scale metadata collection).

There are defenses against this: we can certainly work to increase the cost of inference, through guidelines to inject randomness into non-identifying metadata (at the cost of latency and throughput) in protocols where the identifying metadata and content are already effectively cryptographically protected. End systems and end users still need to be identified by enough of an address to route packets and messages to them, though, and these addresses can generally be mapped to some set of real-world entities as well as a set of real-world locations, so there are limits to how far we can go within the present architecture. (Randy's suggestion to encrypt BGP to make passive network topology observation more difficult might help here -- though the prospect dismays me as a network researcher with an interest in keeping data as open as possible, it's intriguing from a privacy and security standpoint.)

However, being a perfect passive adversary is terribly expensive and doesn't work nearly as well as just compromising the end systems, whether through the traditional phishing, social engineering, rootkits and keyloggers or through cooperation and court orders, as recent revelations have shown. This illustrates the first limitation:

(1) The most serious threats today reside outside the scope of the network and its protocols. It's not the men in the middle we should be worried about, it's the men at the end. It's not clear that we can do anything about this at all.

The tools of monitoring themselves are also applicable to operations and management, which is where I got started in the IETF, working on the protocols that are perhaps most directly applicable to network monitoring at the scale applicable to pervasive passive surveillance, IPFIX (RFC5101 and draft-ietf-ipfix-protocol-rfc5101bis) and PSAMP (RFC5474-5477). Here, we've defined protocols that by _necessity_ enable large-scale passive data collection. That's what they were designed to do, though of course they were designed with a rather more limited applicability in mind, focusing on billing, capacity planning, troubleshooting, and forensics and security monitoring on enterprise networks.

It was through working on these protocols that I remember that the IETF made a policy statement on passive surveillance in the form of wiretapping (full content delivery to a third party) thirteen years ago. RFC 2804 states, in essence, that requirements for wiretapping are not to be considered in the creation and maintenance of IETF standards, though the reasoning presented behind this is rather more motivated by practical concerns than an inherent desire to protect communications. 

RFC 2804 has been generally cited as "we don't do wiretapping here", to the extent that the security considerations of RFC 5476 (PSAMP) state that "[t]he PSAMP Device SHOULD NOT export the full payload of conversations, as this would mean wiretapping [RFC2804].  The PSAMP Device MUST respect local privacy laws" -- in effect, though this is not the _spirit_ of the statement, we say that a device in a jursidiction with weak privacy laws with a full-payload sampling probability of 0.99 is compliant, while one with a sampling probability of 1.00 is not. This illustrates a second issue, which I think can be generalized (but maybe I only think this because I'm a measurement geek):

(2) Most (perhaps all) technologies that can be applied to passive network measurement for operations and management purposes can be applied to pervasive passive network surveillance: the only difference is one of configuration and deployment.

To me, this indicates we'll probably end up focusing more on configuration and implementation guidance than on changing protocols, except in those cases where protocols need specific support for cryptography which they presently lack. This is probably a good thing.

We spent a good deal of time thinking about these issues a few years ago in the FP7-PRISM project (http://fp7-prism.eu) (no, not that PRISM; yes, I appreciate the irony). PRISM essentially placed all configuration decisions for measurement in the hands of a "privacy-preserving controller", which would issue certificates bound to configuration operations only if these passed a verification of the operation, identity of the requestor, and purpose for which the request was made. It also had the ability to degrade passive measurement configurations (i.e. "you want full flow data, but have stated no purpose for which that is allowed; here are 5-minute bins grouped by AS instead"). The main problem with making something like this work is you need a formal language to define all the possible things you can do with passively-obtained measurement data so that you can do the verification. You also need a trusted privacy-preserving controller which can sanction a requestor for stating a false purpose -- in PRISM, we presumed this would be a national data projection authority. But the architectural principles may be applicable to "privacy by default" management infrastructures.

As far as the impact of management protocols on passive surveillance, we can certainly issue more concrete statements about the IETF's position on the use of such protocols, a la 2804, that we do not endorse configurations supporting surveillance activities, but at the same time it would be hard to redefine these protocols in a way to make their misuse for surveillance more difficult without fundamentally disabling them for their legitimate purposes. People are free to roundly ignore any configuration advice we give, and generally will when there's no interoperability benefit not to, so it's not clear that this would have a great deal of impact.

In general, though, focusing on protocols where necessary, configuration where possible, and advice everywhere else seems like a good approach.

Best regards,

Brian

[1] on one of the networks I'm doing research on, I was happily surprised to see Port 443 flows very slightly outnumber Port 80 flows for the first time in April of this year: HTTPS everywhere seems to be having its intended effect. :)

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 18 Aug 2013 22:47:26 +0100

Hi Brian,

First, thanks for the thoughtful post. You make some good points.
A few responses below. Might be better to follow up in separate
mails, since you raise too many interesting points probably:-)

On 08/18/2013 07:45 PM, Brian Trammell wrote:
> Greetings, all,
> 
> On the floor of my home directory, there are notes for a paper we
> never finished called "The Perfect Passive Adversary"; intended as a
> survey of the state of the network security and measurement
> literature and practice to explain what is possible if one assumes an
> adversary which can (1) observe every packet of every communication
> at every point within a network but (2) does not have access to the
> endpoints beyond the network interface (i.e. no keyloggers, and no
> bulk access to user data at a service provider) and (3) cannot
> influence packet forwarding. It grew to be rather too wide in scope
> and too paranoid in tone to have a realistic chance at publication,
> so we dropped it, which in retrospect seems a silly choice.

So publish it! As an I-D even:-) But if you have a version that
you're happy to share, that'd be great to see.

> I would propose that we consider this as one of the threat models we
> address; the exercise I propose is to examine the protocols we're
> familiar with and think about (1) what's in the payload, (2) what can
> be inferred from identifying metadata (IP addresses and port numbers,
> application-layer addresses (email addresses, URLs, etc) (3) what can
> be inferred from non-identifying metadata (data volume and packet
> counts, interarrival times,  control information such as sequence
> numbers, and so on).

Taking a look at [1] would be good also for folks who weren't at the
TLS wg session in Berlin - an 83% probability of identifying users
based on the size of their FB avatar images as sent over TLS is an
interesting result I think.

   [1] http://www.ietf.org/proceedings/87/slides/slides-87-tls-3.pdf

But I absolutely agree that if we can somehow inventory the protocols
which we know (each of us having different knowledge) from this pov
that'd be valuable. (I'm hoping someone jumps in now to say they're
interested in writing that up as an I-D or wiki or something.)

> It looks like this conversation is already well underway on the email
> side of the house, which is good. :) What follows are some further
> musings on the limitations of this approach.
> 
> In general, increasing use of end-to-end transport encryption[1]
> mitigates the threat of eavesdropping by a man in the middle; indeed,
> threat models involving intermediate eavesdropping are at this point
> extremely well understood, and well defended against, barring
> problems with the crypto protocols that I'm not a good enough
> cryptographer to understand.  A perfect passive adversary generally
> won't even bother trying to break this link: it's too strong, a
> testament to the attention that's been paid to it over the decades.
> Such an adversary could look for unprotected side-channels (e.g., SSH
> keystroke timing attacks, static HTTPS content size/timing
> fingerprints), or could give up on payload altogether and attempt to
> make inferences just from the flow keys (this being the point of
> large-scale metadata collection).

Well... the DNS records you look up, the .js & .jpg files you download
(and when), the src/dest/port of various things... seems like there's
maybe a lot that's there today. Not to mention the times when how to
do crypto stuff is well defined but not used (RADIUS/Diameter as an
example?)

I think the inventory you suggest would be a fine thing were it to
emerge from this list, esp. with a pervasive passive monitor in
mind - which I don't think most of us have usually included in our
threat models.

> 
> There are defenses against this: we can certainly work to increase
> the cost of inference, 

Yes, that's a good goal. But we also need to try understand how
effective it might be, and at what cost.

> through guidelines to inject randomness into
> non-identifying metadata (at the cost of latency and throughput) in
> protocols where the identifying metadata and content are already
> effectively cryptographically protected. End systems and end users
> still need to be identified by enough of an address to route packets
> and messages to them, though, and these addresses can generally be
> mapped to some set of real-world entities as well as a set of
> real-world locations, so there are limits to how far we can go within
> the present architecture. (Randy's suggestion to encrypt BGP to make
> passive network topology observation more difficult might help here
> -- though the prospect dismays me as a network researcher with an
> interest in keeping data as open as possible, it's intriguing from a
> privacy and security standpoint.)

Agree.

> 
> However, being a perfect passive adversary is terribly expensive and
> doesn't work nearly as well as just compromising the end systems,
> whether through the traditional phishing, social engineering,
> rootkits and keyloggers or through cooperation and court orders, as
> recent revelations have shown. 

One interpretation of the current news stories might be that its
not so expensive to compromise some almost random but "nearby" end
systems and have those contribute to your monitoring network. I
could believe that its more expensive to very specifically target
an attack at one end-system, particularly if you want to disguise
the fact that you tried.

> This illustrates the first
> limitation:
> 
> (1) The most serious threats today reside outside the scope of the
> network and its protocols. It's not the men in the middle we should
> be worried about, it's the men at the end. It's not clear that we can
> do anything about this at all.

I'd quibble a bit there. We spec protocols at many layers, and what's
an endpoint for one, is the middle for others.

> 
> The tools of monitoring themselves are also applicable to operations
> and management, which is where I got started in the IETF, working on
> the protocols that are perhaps most directly applicable to network
> monitoring at the scale applicable to pervasive passive surveillance,

Yep, that's a real issue - to what extent is it possible to be more
robust against a pervasive passive monitor without buggering up n/w
mgmt. I don't know the answer, but that's where the E in IETF should
come into play.

> IPFIX (RFC5101 and draft-ietf-ipfix-protocol-rfc5101bis) and PSAMP
> (RFC5474-5477). Here, we've defined protocols that by _necessity_
> enable large-scale passive data collection. That's what they were
> designed to do, though of course they were designed with a rather
> more limited applicability in mind, focusing on billing, capacity
> planning, troubleshooting, and forensics and security monitoring on
> enterprise networks.
> 
> It was through working on these protocols that I remember that the
> IETF made a policy statement on passive surveillance in the form of
> wiretapping (full content delivery to a third party) thirteen years
> ago. RFC 2804 states, in essence, that requirements for wiretapping
> are not to be considered in the creation and maintenance of IETF
> standards, though the reasoning presented behind this is rather more
> motivated by practical concerns than an inherent desire to protect
> communications.
> 
> RFC 2804 has been generally cited as "we don't do wiretapping here",
> to the extent that the security considerations of RFC 5476 (PSAMP)
> state that "[t]he PSAMP Device SHOULD NOT export the full payload of
> conversations, as this would mean wiretapping [RFC2804].  The PSAMP
> Device MUST respect local privacy laws" -- in effect, though this is
> not the _spirit_ of the statement, we say that a device in a
> jursidiction with weak privacy laws with a full-payload sampling
> probability of 0.99 is compliant, while one with a sampling
> probability of 1.00 is not. This illustrates a second issue, which I
> think can be generalized (but maybe I only think this because I'm a
> measurement geek):
> 
> (2) Most (perhaps all) technologies that can be applied to passive
> network measurement for operations and management purposes can be
> applied to pervasive passive network surveillance: the only
> difference is one of configuration and deployment.
> 
> To me, this indicates we'll probably end up focusing more on
> configuration and implementation guidance than on changing protocols,
> except in those cases where protocols need specific support for
> cryptography which they presently lack. This is probably a good
> thing.
> 
> We spent a good deal of time thinking about these issues a few years
> ago in the FP7-PRISM project (http://fp7-prism.eu) (no, not that
> PRISM; yes, I appreciate the irony). 

Are there any of the publications/deliverables from that that'd
be a good read for folks on this list? (The site has too much to
digest tonight:-)

Cheers,
S.

> PRISM essentially placed all
> configuration decisions for measurement in the hands of a
> "privacy-preserving controller", which would issue certificates bound
> to configuration operations only if these passed a verification of
> the operation, identity of the requestor, and purpose for which the
> request was made. It also had the ability to degrade passive
> measurement configurations (i.e. "you want full flow data, but have
> stated no purpose for which that is allowed; here are 5-minute bins
> grouped by AS instead"). The main problem with making something like
> this work is you need a formal language to define all the possible
> things you can do with passively-obtained measurement data so that
> you can do the verification. You also need a trusted
> privacy-preserving controller which can sanction a requestor for
> stating a false purpose -- in PRISM, we presumed this would be a
> national data projection authority. But the architectural principles
> may be applicable to "privacy by default" management
> infrastructures.
> 
> As far as the impact of management protocols on passive surveillance,
> we can certainly issue more concrete statements about the IETF's
> position on the use of such protocols, a la 2804, that we do not
> endorse configurations supporting surveillance activities, but at the
> same time it would be hard to redefine these protocols in a way to
> make their misuse for surveillance more difficult without
> fundamentally disabling them for their legitimate purposes. People
> are free to roundly ignore any configuration advice we give, and
> generally will when there's no interoperability benefit not to, so
> it's not clear that this would have a great deal of impact.
> 
> In general, though, focusing on protocols where necessary,
> configuration where possible, and advice everywhere else seems like a
> good approach.
> 
> Best regards,
> 
> Brian
> 
> 
> [1] on one of the networks I'm doing research on, I was happily
> surprised to see Port 443 flows very slightly outnumber Port 80 flows
> for the first time in April of this year: HTTPS everywhere seems to
> be having its intended effect. :) 
> _______________________________________________ perpass mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/perpass
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 18 Aug 2013 19:44:02 -0600

On 8/18/13 3:47 PM, Stephen Farrell wrote:
>> I would propose that we consider this as one of the threat models
>> we address; the exercise I propose is to examine the protocols
>> we're familiar with and think about (1) what's in the payload,
>> (2) what can be inferred from identifying metadata (IP addresses
>> and port numbers, application-layer addresses (email addresses,
>> URLs, etc) (3) what can be inferred from non-identifying metadata
>> (data volume and packet counts, interarrival times,  control
>> information such as sequence numbers, and so on).
> 
> Taking a look at [1] would be good also for folks who weren't at
> the TLS wg session in Berlin - an 83% probability of identifying
> users based on the size of their FB avatar images as sent over TLS
> is an interesting result I think.
> 
> But I absolutely agree that if we can somehow inventory the
> protocols which we know (each of us having different knowledge)
> from this pov that'd be valuable.

I've thought about this over the last few months in relation to
XMPP-based instant messaging. My conclusions are (a) XMPP cannot be
made into a privacy-protecting technology (even if we could settle on
a sustainable approach to end-to-end encryption) and (b) we'll need to
develop new technologies that are universally encrypted, don't rely on
DNS-based addresses, a federated network of servers, etc.

I still think there is value in pushing for universal TLS for both
client-to-server and server-to-server connections in XMPP, publishing
an RFC for OTR and encouraging more implementations thereof, and so
on. However, I'm not confident that such improvements will address the
fundamental issues that have arisen over the last few months.

> (I'm hoping someone jumps in now to say they're interested in
> writing that up as an I-D or wiki or something.)

Right now I'm more interested in helping out on code and spec work
related to a project that I think has promise.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Brian Trammell <[email-masked]>
Date: Mon, 19 Aug 2013 09:00:46 +0200

hi Stephen, all,

Yeah, sorry for the giant multitopic rant. I'll split this out into a few threads to continue...

> you're happy to share, that'd be great to see.

I dusted this off and had a look at it last night, and it's in worse shape than I'd thought as a coherent piece of work. But completing it (to -00 I-D quality, at least) and publishing an I-D -- especially given the scope of the conversation on this list -- seems like a great idea. I'll get started.

> interested in writing that up as an I-D or wiki or something.)

Wasn't at the TLS WG, thanks for the pointer! This is a specific case of the general metadata fingerprinting problem (which, incidentally, is why I don't believe in anonymization any more). It's good to see awareness of this spreading.

> do crypto stuff is well defined but not used (RADIUS/Diameter as an

DNS radiates a _whole lot_ of information, and does so all over the place: if you own the path to an anycast instance of a root server, you get a 1/n sample of every query on the Internet not cached at a recursive resolver. It's at least widely used in stateless censorship (see Anonymous, "The Collateral Damage of Internet Censorship by DNS injection", ACM CCR July 2012); we must assume it's in wide use for pervasive monitoring as well.

> mind - which I don't think most of us have usually included in our

I'll get started on the perfect passive adversary I-D -- at least to define the threat model a bit -- hopefully in the coming couple of weeks (under a bit of deadline pressure at the moment :/ ) I could certainly also coordinate contributions of specific instances of information radiation coming off of various protocols into this I-D.

Best regards,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Mon, 19 Aug 2013 09:01:30 +0200

hi Stephen, all,

> On 08/18/2013 07:45 PM, Brian Trammell wrote:

<snip>

> mgmt. I don't know the answer, but that's where the E in IETF should

One of the bits of relatively obvious guidance that came out of PRISM was "throw away what you don't need as early as you can": an added bonus is that this makes passive measurement scale a lot better too, because you're not keeping around a lot of useless state. This is a little contrary to the practice of science -- collect all you can and analyze later -- but has a real impact on the privacy risk of these technologies. In jurisdictions with serious privacy laws, it's the only way to operate. For example (hey look, another anecdote! ;) ) a few years ago [1], Google was cited by the German data protection authority for driving Street View cars around and saving all the (open) wireless traffic they saw -- including partial payload -- in order to do a later analysis of BSSIDs seen for geolocation purposes. Presumably this was either a packet capture misconfiguration or a bit of engineering laziness, which could have been avoided simply by making the software in the cars smarter about what they kept.

In passive monitoring for management and operations, this means each collection activity should have a specified purpose, and information irrelevant to that purpose simply shouldn't be collected at the observation point. This is admittedly easier for some things (passive performance characterization) than for others (billing and troubleshooting, both of which need to identify the endpoints). 

There's a metarequirement here, which should be explicitly stated: anything we do to protect a protocol against passive monitoring should take the manageability of the result into account.

> be a good read for folks on this list? (The site has too much to

Unfortunately, in the public deliverables, not really; they're all a bit too wordy to jump into and really understand what's going on, and the target moved a bit during the project, which makes it difficult to start at  the introductory material and understand where we ended up. Originally, we were looking into using homomorphic encryption in network monitoring -- projecting filtering and aggregation operations into encrypted data space, and decrypting only the results -- but this turned out (perhaps not surprisingly) not to scale very well.

There's a very quick and inadequately detailed introduction to the architecture in "An introduction to IPFIX", IEEE Communications Magazine, April 2011. Sections 2 and 3.1 of http://telscom.ch/wp-content/uploads/Prism/FP7-PRISM-WP2.2-D2.2.2.pdf are reasonably understandable on their own; the rest of the document gets very rapidly into the gory details.

In any case, I'd suggest taking architectural guidance from the general pattern of usage (separating measurement configuration control from measurement configuration, protecting the channel with single-use credentials) as opposed to trying to implement PRISM as is.

Best regards,

Brian

[1] http://googleblog.blogspot.ch/2010/05/wifi-data-collection-update.html

---

From: Brian Trammell <[email-masked]>
Date: Mon, 19 Aug 2013 09:03:04 +0200

hi Stephen, all,

and on a third topic, briefly...

> an attack at one end-system, particularly if you want to disguise

True. Bots get more expensive the more specific you want to be about where and what they are. But here you're compromising end systems and using them as middle systems, which is a bit different than owning the end host of a targeted individual, turning on his webcam, and having a look around his flat.

One of the points of the perfect passive adversary attack model is that it illustrates that you don't really _need_ to compromise the ends to get a _whole lot_ of information. When the passive monitoring is done at the physical layer, you can't even detect its presence from the ends. Sitting at the endpoints is infinitely more detectable, and you have to conceal your presence through technical and/or legal countermeasures. 

> an endpoint for one, is the middle for others.

Point. I don't mean that it's useless to work on better securing the middle -- anything we can do to increase the cost of indiscriminate, pervasive passive surveillance is a Good Thing. I'm just saying that we shouldn't be surprised when the reaction to the increased cost of pervasive passive monitoring at layers 1 through 7 is a layer 9 attack: new legislation compelling every access provider, service provider, and blogger with comments on in a given jurisdiction to deliver detailed application-level logging information to the authority designated for the purpose.

Best regards,

Brian