Re: [TLS] TLS-OBC and channel-bound cookies as a new TLS CB type (Re: TLS-OBC proposal)

Nico Williams <> Thu, 08 September 2011 21:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 24E7E21F8B3F for <>; Thu, 8 Sep 2011 14:30:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.695
X-Spam-Status: No, score=-2.695 tagged_above=-999 required=5 tests=[AWL=-0.718, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8xfwRDvbr4MB for <>; Thu, 8 Sep 2011 14:30:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 72B1C21F8ACC for <>; Thu, 8 Sep 2011 14:30:56 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 46FFA428076 for <>; Thu, 8 Sep 2011 14:32:49 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s=; b=BveKpvsBVypmQDYQgpENW/k6h9Dz6o6jlZTZxKJFPS+e mYPW4yhEOgFLNJrORPJS2lqaTQi4yDKm+LdhM9U9ZXCktkNvkhsXFqzIplgMzTI1 lJpeT0GT5W3pGQUrhItor82ReKe2zyuq/iUmkK3Vu8yMIAgTSodXYCzIovC8MWA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s=; bh=t8VkfQNXCpwAUZjO0jAcKyySRNY=; b=BliLq6/OrLi C1PX/46KEgFZu5N4WKEPnuijNx3u6o3DVg0rm8C67nNGqdOGxOuwIlqmGEyTsS4r jOLZZvkxWZxFGmbTR1yBwgsEitOm7t5GdKDa+znbtZozD/R1QHeqCDqDmE6+iPGg jyCN0Ta5o3MLYea2b9SSk9akcCgesS74=
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id E43D742806E for <>; Thu, 8 Sep 2011 14:32:47 -0700 (PDT)
Received: by gxk9 with SMTP id 9so430814gxk.40 for <>; Thu, 08 Sep 2011 14:32:47 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id q10mr1838657pbs.131.1315517566796; Thu, 08 Sep 2011 14:32:46 -0700 (PDT)
Received: by with HTTP; Thu, 8 Sep 2011 14:32:46 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Thu, 8 Sep 2011 16:32:46 -0500
Message-ID: <>
From: Nico Williams <>
To: Dirk Balfanz <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [TLS] TLS-OBC and channel-bound cookies as a new TLS CB type (Re: TLS-OBC proposal)
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Sep 2011 21:30:57 -0000

On Thu, Sep 8, 2011 at 4:22 PM, Dirk Balfanz <> wrote:
> On Thu, Sep 8, 2011 at 12:47 PM, Nico Williams <>
> wrote:
>> A digest of an OBC would be the CB data for the new CB type.
> Yes, exactly! I try to say as much
> here: (look for my mention
> of RFC 5929).

I did see it :)  Thanks!

>> The only downside is that we'd need two additional PK operations for
>> all full handshakes.
> Well, if you define "session" as something that survives full new
> handshakes, I guess. I would still call it a new "session", but the same
> "channel", but at this time we're mincing words...

Well, yes, "sessions" here would last no longer than the OBC.  If the
client generates a new OBC, old sessions are dead.  Now, here I'm not
referring to TLS sessions proper, but a new concept of session that is
much more within the control of the client.

So, it's not so much that we're mincing words but that we need to be
real careful with terminology.  This being a mail thread and not an
I-D I got careless with terminology for the sake of brevity :)

>> Note too that what you propose fits RFC 5056 just fine.
> Yes, I noticed that, too.


Is there any way to avoid the need for negotiation of OBC?  I'm
guessing that for some TLS server stacks the use of random self-signed
client certs would result in failure, thus negotiation is necessary.
Is that right?