Re: [perpass] On the perfect passive adversary

Brian Trammell <trammell@tik.ee.ethz.ch> Mon, 19 August 2013 07:01 UTC

Return-Path: <trammell@tik.ee.ethz.ch>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C6F21F98AD for <perpass@ietfa.amsl.com>; Mon, 19 Aug 2013 00:01:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4drRNbwninN0 for <perpass@ietfa.amsl.com>; Mon, 19 Aug 2013 00:00:57 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id D46A621F97E6 for <perpass@ietf.org>; Mon, 19 Aug 2013 00:00:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7EFD6D930A; Mon, 19 Aug 2013 09:00:48 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1hMBIQHlVg4H; Mon, 19 Aug 2013 09:00:48 +0200 (MEST)
Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 2B337D9308; Mon, 19 Aug 2013 09:00:48 +0200 (MEST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Brian Trammell <trammell@tik.ee.ethz.ch>
In-Reply-To: <521140EE.1080309@cs.tcd.ie>
Date: Mon, 19 Aug 2013 09:00:46 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <436E1732-663B-42BF-8CA9-DFE48724D1F6@tik.ee.ethz.ch>
References: <2941892B-9F23-46F9-B993-446D7800A0DF@tik.ee.ethz.ch> <521140EE.1080309@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.1508)
Cc: perpass@ietf.org
Subject: Re: [perpass] On the perfect passive adversary
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/perpass>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Aug 2013 07:01:02 -0000

hi Stephen, all,

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

On Aug 18, 2013, at 11:47 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

> 
> 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 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.

>> 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.)

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.

>> 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?)

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.

> 
> 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.

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