Re: [perpass] Yet Another Reason why ALL CLEARTEXT MUST BE ELIMINATED!

"Christian Huitema" <huitema@huitema.net> Thu, 12 December 2013 04:44 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07D21AE009 for <perpass@ietfa.amsl.com>; Wed, 11 Dec 2013 20:44:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yah6HVvapjDY for <perpass@ietfa.amsl.com>; Wed, 11 Dec 2013 20:44:26 -0800 (PST)
Received: from xsmtp03.mail2web.com (xsmtp23.mail2web.com [168.144.250.186]) by ietfa.amsl.com (Postfix) with ESMTP id 051561AE00F for <perpass@ietf.org>; Wed, 11 Dec 2013 20:44:26 -0800 (PST)
Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1Vqy8I-00081L-Lz for perpass@ietf.org; Wed, 11 Dec 2013 23:44:19 -0500
Received: (qmail 9398 invoked from network); 12 Dec 2013 04:44:17 -0000
Received: from unknown (HELO HUITEMA5) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender <huitema@huitema.net>) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for <nweaver@icsi.berkeley.edu>; 12 Dec 2013 04:44:17 -0000
From: Christian Huitema <huitema@huitema.net>
To: 'Nicholas Weaver' <nweaver@icsi.berkeley.edu>, 'perpass' <perpass@ietf.org>
References: <0932E601-895B-457B-9F2D-DD79626AE0F0@icsi.berkeley.edu>
In-Reply-To: <0932E601-895B-457B-9F2D-DD79626AE0F0@icsi.berkeley.edu>
Date: Wed, 11 Dec 2013 20:44:16 -0800
Message-ID: <001601cef6f4$d0f84df0$72e8e9d0$@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQJ263E1zdoccH5QFLMtPiSsSJg56JkADFEA
Content-Language: en-us
Subject: Re: [perpass] Yet Another Reason why ALL CLEARTEXT MUST BE ELIMINATED!
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <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: Thu, 12 Dec 2013 04:44:27 -0000

> Cookies and user tracking are wonderful things.  If you are a intelligence service, that is.

We actually described that attack in draft-trammell-perpass-ppa-01, which we submitted last month:

   4.3.5.  Tracking address use with web cookies

   Many web sites only encrypt a small fraction of their transactions.
   A popular pattern was to use HTTPS for the login information, and
   then use a "cookie" to associate following clear-text transactions
   with the user's identity.  Cookies are also used by various
   advertisement services to quickly identify the users and serve them
   with "personalized" advertisements.  Such cookies are particularly
   useful if the advertisement services want to keep tracking the user
   across multiple sessions that may use different IP addresses.

   As cookies are sent in clear text, a PPA can build a database that
   associates cookies to IP addresses for non-HTTPS traffic.  If the IP
   address is already identified, the cookie can be linked to the user
   identify.  After that, if the same cookie appears on a new IP
   address, the new IP address can be immediately associated with the
   pre-determined identity.

Your analysis goes one step further, linking cookies to active attacks. We only considered "pervasive passive attacks" in the problem statement, but it is pretty clear that we want to also consider the active attacks. Packet injection can act as an efficiency multiplier on top of the passive monitoring.

In any case, it is pretty clear that if a connection carries identifying data such as cookies, then it should be encrypted. Alternately, we may want to convince browser developers to allow a privacy setting "no cookies in clear text."

-- Christian Huitema