Re: [TLS] Addressing cookie theft (think BEAST) with channel bound cookies using TLS session IDs

Nico Williams <nico@cryptonector.com> Thu, 29 September 2011 14:22 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8781F21F8C51 for <tls@ietfa.amsl.com>; Thu, 29 Sep 2011 07:22:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.558
X-Spam-Level:
X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=-0.581, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 ch1IV+0lSiDp for <tls@ietfa.amsl.com>; Thu, 29 Sep 2011 07:22:35 -0700 (PDT)
Received: from homiemail-a16.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 0127021F8C37 for <tls@ietf.org>; Thu, 29 Sep 2011 07:22:34 -0700 (PDT)
Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 4363650807F for <tls@ietf.org>; Thu, 29 Sep 2011 07:25:21 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=XvV3q+8RdzqJxSAV6sqPBItTJfxF8oJ9yfj2QSvBbJSc NO3IUoXBEHSkF62t2nyF3QIbeQIi6EtTYjy7pDh0aL55zSLWXTRkTmhd9LY4Qyws WXygh4ltboHQ8PQObenDeH2CstrDkmSJJPyN6kbCJK+Lu9woNpWkb1K634yiHqU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=9PNlrmPozoLMasqABpV3vqP1S/o=; b=gHsmoU+V716 5VO3N2te3ItdqD59PbCsVyQnemPKht9J42V4RYzPkohv1lC9ht+ZkWaaHl7qPNkH q/mw1KJmj8Lr+Lj2rZnIcDJmzSLNsOrYKASQEVSI8sIJKrVErRZu/uFWtwP9tzYV /lngRdjJdMInx13lVjaTbWG7YkpFcwZc=
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 169DD50807C for <tls@ietf.org>; Thu, 29 Sep 2011 07:25:21 -0700 (PDT)
Received: by vcbfo11 with SMTP id fo11so737594vcb.31 for <tls@ietf.org>; Thu, 29 Sep 2011 07:25:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.44.103 with SMTP id d7mr26048126pbm.24.1317306320117; Thu, 29 Sep 2011 07:25:20 -0700 (PDT)
Received: by 10.68.71.138 with HTTP; Thu, 29 Sep 2011 07:25:20 -0700 (PDT)
In-Reply-To: <82mxdny61z.fsf@mid.bfk.de>
References: <CAK3OfOjKwn16uKN44AjDDYoFxJwdghK=21zEKr6zSrp4gzATFQ@mail.gmail.com> <82mxdny61z.fsf@mid.bfk.de>
Date: Thu, 29 Sep 2011 09:25:20 -0500
Message-ID: <CAK3OfOg1zJj3pMNNeLFdxyZd7T-6-75pRRk+NF20TemGsEY29Q@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Florian Weimer <fweimer@bfk.de>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: tls@ietf.org
Subject: Re: [TLS] Addressing cookie theft (think BEAST) with channel bound cookies using TLS session IDs
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Sep 2011 14:22:35 -0000

On Thu, Sep 29, 2011 at 5:52 AM, Florian Weimer <fweimer@bfk.de> wrote:
> * Nico Williams:
>
>> A while back Dirk Balfanz proposed something he called "origin bound
>> certificates" and "channel bound cookies".  A lighter-weight
>> alternative (i.e., involving no protocol changes) would be nice.
>> Mine: use TLS session IDs as the channel binding.
>
> If we're interested in working around the cookie issue (as opposed to
> fixing the protocol issue), I think it would be simpler to include a
> random prefix in the cookie, ignored by the server, and the server would
> change the prefix every few requests.

I don't see how that would stop BEAST.  And, in any case, would
require changes to clients and servers both, which makes it much
harder to deploy.

Nico
--