IETF Logo Mail Archive

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

Nico Williams <nico@cryptonector.com> Wed, 28 September 2011 21:02 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 D77B91F0CD2 for <tls@ietfa.amsl.com>; Wed, 28 Sep 2011 14:02:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.584
X-Spam-Level:
X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=-0.607, 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 Csvx9p4Yjylg for <tls@ietfa.amsl.com>; Wed, 28 Sep 2011 14:02:17 -0700 (PDT)
Received: from homiemail-a89.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3241F0C8B for <tls@ietf.org>; Wed, 28 Sep 2011 14:02:17 -0700 (PDT)
Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id A0211318070 for <tls@ietf.org>; Wed, 28 Sep 2011 14:05:06 -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=EFIOIpejq9cSJPhh341aIR3au6/PranrjOXV8ruPSSRT qNvDBVAVkmd9wmMYFOtwbRKMoZiFZoWRcHDxh3CpxpkqSIrrV7bVj7iA3ZGL7hnw eI8K3oNPwqov+uB176AJHjB97twgwmCjWYP8YfDkIld1U+MprL+/9pCRy4dzke8=
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=fAqnI0Ak24P+1qHZZ864aDUYaDA=; b=EuB2kgPnfws p5Leop0007jpGtG4iFtB1jLJoK+fIlpP7b676ZtY9WxGotjL2VL15TfXjdBAWzyb h+693BYp+ZQyKxoCfhCrUyZFyPVrbjihucrL8887prKoHqkP4cglB/+oF6aOVZmr dgtffmlBXfaXHCoxwEi7YRxc3vdGIvAQ=
Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 8278231806D for <tls@ietf.org>; Wed, 28 Sep 2011 14:05:06 -0700 (PDT)
Received: by pzk37 with SMTP id 37so22431585pzk.9 for <tls@ietf.org>; Wed, 28 Sep 2011 14:05:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.56.225 with SMTP id d1mr47298015pbq.109.1317243906176; Wed, 28 Sep 2011 14:05:06 -0700 (PDT)
Received: by 10.68.71.138 with HTTP; Wed, 28 Sep 2011 14:05:06 -0700 (PDT)
In-Reply-To: <E4076194-2A43-4282-B282-37B14CBCB488@checkpoint.com>
References: <CAK3OfOjKwn16uKN44AjDDYoFxJwdghK=21zEKr6zSrp4gzATFQ@mail.gmail.com> <E4076194-2A43-4282-B282-37B14CBCB488@checkpoint.com>
Date: Wed, 28 Sep 2011 16:05:06 -0500
Message-ID: <CAK3OfOjLDSmgSQUQM+zJAzk8DSuRc7FGDQ=pMHk-5v2M5aMgGg@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Yoav Nir <ynir@checkpoint.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "tls@ietf.org" <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: Wed, 28 Sep 2011 21:02:18 -0000

On Wed, Sep 28, 2011 at 4:01 PM, Yoav Nir <ynir@checkpoint.com> wrote:
> If the server-side HTTP stack has that, why would such an application even need cookies? Cookies are generally keys to a saved server-side state. If you have access to the TLS session ID, you might as well use that as the key to the saved server-side state.

This is true.  And if that's the end state, so much the better.  But
so much of the web depends on cookies that an incremental solution
that doesn't do much violence to the stack would be nice.

Nico
--

v2.23.0 | Report a Bug | By Email