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

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 
> perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass
> 