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

Nico Williams <nico@cryptonector.com> Sat, 19 November 2011 19:03 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 3CF2221F85B1 for <tls@ietfa.amsl.com>; Sat, 19 Nov 2011 11:03:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.19
X-Spam-Level:
X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=-0.213, 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 Of0wCi4f1tWX for <tls@ietfa.amsl.com>; Sat, 19 Nov 2011 11:03:26 -0800 (PST)
Received: from homiemail-a85.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id C72A821F85AE for <tls@ietf.org>; Sat, 19 Nov 2011 11:03:26 -0800 (PST)
Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id 561D2BC041 for <tls@ietf.org>; Sat, 19 Nov 2011 11:03:26 -0800 (PST)
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=KS+rEqPvZznuP+EbkcnpMo0pM+yLRxXX9ZeAkWe/y2pK Q/CG3QIZn6jAIVYoAVSf7bFOG6R20pZ45JkHDthYMqe+7VQXNu6e/c8kOWHqGmA6 1bgGBzI1/9FPWHJDC89MrGt8yDPLTO4cLONviDE8fi9ePSXY70IQX13XF9MM84E=
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=EyXt07Ekynkdhg7chuXhtFeGoaA=; b=aUjuoJ2T4mZ IueBXSOLmZ9j5QJhu5GneqzQzWYlCsJVFnPTX/vHBw7m4uGrPOtoQ3h/cu9ks9Ti oH/qwuTsCtOSaWKmYt/tzrN7/wU3Mf9480pmNRmRTYqWq9DaLPi0XUffNcSf7tHh tv/EG93UTJSm0H983WsB31KyKA5F3HDU=
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPSA id 389B0BC040 for <tls@ietf.org>; Sat, 19 Nov 2011 11:03:26 -0800 (PST)
Received: by yenm7 with SMTP id m7so1130742yen.31 for <tls@ietf.org>; Sat, 19 Nov 2011 11:03:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.30.68 with SMTP id q4mr15995171pbh.75.1321729405160; Sat, 19 Nov 2011 11:03:25 -0800 (PST)
Received: by 10.68.192.70 with HTTP; Sat, 19 Nov 2011 11:03:25 -0800 (PST)
In-Reply-To: <432A7B23-0128-4EAC-B9E3-1A4DB718D8DC@checkpoint.com>
References: <OFC57A0976.6BDE818B-ON4825794C.0031B1B5-4825794C.00326539@zte.com.cn> <CAK3OfOi3P4ZJebfHN2WyGR5w3nDu35vy7wF7ZjbjGnpYg=mLuA@mail.gmail.com> <432A7B23-0128-4EAC-B9E3-1A4DB718D8DC@checkpoint.com>
Date: Sat, 19 Nov 2011 13:03:25 -0600
Message-ID: <CAK3OfOgw4KhR8TP1jR3HgV2mMaggEsBi+2ToY3Q7Yzii574y2A@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] 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 19:03:27 -0000

On Sat, Nov 19, 2011 at 5:15 AM, Yoav Nir <ynir@checkpoint.com> wrote:
> On Nov 18, 2011, at 11:34 PM, Nico Williams wrote:
> I we can find no other use case, we might want to rename it to "Origin Bound Cookie".

The cookies are not bound to origins.  They are bound to -effectively-
sessions (I don't mean TLS sessions strictly speaking).

So if you want to take "certificates" out of the name you'd have to
take "origin" out also.

> But that would require some interesting interaction between layers.

OBC requires interaction between layers: the layer that sets and
validates cookies must interact with the TLS layer.

> Are all cookies received while using OBC considered (by the
> client!) bound to the OBC? If not, the client might use an old

The client has no way to verify the cookie bindings.  Only the server
can do that.

The client has the power to make the cookie bindings (when they are
bound) impossible to verify.

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

We may want -but don't strictly- need a way for servers to tell
clients which cookies are bound and which aren't.  The client can, of
course, apply some heuristics, such as "secure-only cookies where the
server supports OBC and we used OBC must be bound" and "all other
cookies can't be bound or the binding isn't critical to the server".

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

This needs more elaboration, clearly.  What I said was that the client
can enforce a logout (well, when the server really wants valid bound
cookies).  A logout that involves both, the client and the server will
require some protocol work, but that wouldn't be strictly necessary
(we manage today...).

Nico
--