Re: [TLS] concers about draft-balfanz-tls-obc

Yoav Nir <ynir@checkpoint.com> Sat, 19 November 2011 11:15 UTC

Return-Path: <ynir@checkpoint.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 2026721F893C for <tls@ietfa.amsl.com>; Sat, 19 Nov 2011 03:15:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.425
X-Spam-Level:
X-Spam-Status: No, score=-10.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 qU--+mNGswrz for <tls@ietfa.amsl.com>; Sat, 19 Nov 2011 03:15:43 -0800 (PST)
Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 32FF321F88B6 for <tls@ietf.org>; Sat, 19 Nov 2011 03:15:42 -0800 (PST)
X-CheckPoint: {4EC78F6F-0-1B221DC2-1FFFF}
Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pAJBFYJ0007556; Sat, 19 Nov 2011 13:15:34 +0200
Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 19 Nov 2011 13:15:34 +0200
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sat, 19 Nov 2011 13:15:34 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Nico Williams <nico@cryptonector.com>
Date: Sat, 19 Nov 2011 13:15:32 +0200
Thread-Topic: [TLS] concers about draft-balfanz-tls-obc
Thread-Index: AcymrI3JPGVb4KJCQhCVm248ytoGug==
Message-ID: <432A7B23-0128-4EAC-B9E3-1A4DB718D8DC@checkpoint.com>
References: <OFC57A0976.6BDE818B-ON4825794C.0031B1B5-4825794C.00326539@zte.com.cn> <CAK3OfOi3P4ZJebfHN2WyGR5w3nDu35vy7wF7ZjbjGnpYg=mLuA@mail.gmail.com>
In-Reply-To: <CAK3OfOi3P4ZJebfHN2WyGR5w3nDu35vy7wF7ZjbjGnpYg=mLuA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-KSE-AntiSpam-Interceptor-Info: protection disabled
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] concers about draft-balfanz-tls-obc
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: Sat, 19 Nov 2011 11:15:44 -0000

On Nov 18, 2011, at 11:34 PM, Nico Williams wrote:
>>    2. If client authentication is not required, then there is neither need
>> to send a self-signed certificate.
> 
> Client authentication is orthogonal to OBC.
> 
> OBC protects the session cookies from theft.  Let's say you steal my
> session cookies somehow (e.g., via the BEAST attack): but if you don't
> have my OBCs' private keys then you can't actually make use of my
> cookies.
> 
> With OBC cookie theft is not enough.  With OBC the attacker must get
> at the private keys for the OBCs.
> 
> Also, with OBC you get closer to true logout: destroy ("forget") your
> OBC private keys and your sessions are as good as dead.  Moreover, the
> user-agent, not the server, is in control of maximum session lifetime,
> since there's no point in the server setting cookies that will outlive
> the OBCs. 

I we can find no other use case, we might want to rename it to "Origin Bound Cookie".

But that would require some interesting interaction between layers. 

Are all cookies received while using OBC considered (by the client!) bound to the OBC? If not, the client might use an old cookie after a logout event, leading to the server falsely detecting an attempt to forge a cookie. Maybe we need a new keyword on the cookie header.

Where is the "logout" button?  If it's part of the website (in the "canvas") how does the HTML/HTTP tell the browser to log out? Probably best to have it in the Chrome for sites where OBC are supported.