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

From: Nico Williams <[email-masked]>
Date: Thu, 8 Sep 2011 14:47:49 -0500

One way to think about what you're proposing is this: you're proposing
a new TLS session identification and resumption facility and a new
channel binding type whose CB data that are unique for each session
but the same for all connections in that session.

The session ID here would be the client's ephemeral (private key
thrown away between sessions) self-signed cert.

Session resumption here would come in two forms: proper TLS session
resumption, and new TLS sessions using an existing OBC.  For the
latter case there'd be neither server-side state nor state cookies --
clever!

A digest of an OBC would be the CB data for the new CB type.

I find your idea very clever.

The only downside is that we'd need two additional PK operations for
all full handshakes.

Note that we could instead use a new TLS CB type named, say,
tls-session-unique, defined as follows: the CB data will be as for
tls-unique for a TLS session's full handshake.  This would avoid the
need to negotiate the use/non-use of OBC, and it'd avoid the need to
add a pair of PK operations.  But it'd also make the system more
dependent on TLS session resumption.  I suspect that given a choice of
"more PK ops" vs "session resumption becomes more important" then
people will prefer the former.

Note too that what you propose fits RFC 5056 just fine.  We could and
should register a new CB type for OBC if OBC progresses.

Nico
--

---

From: Dirk Balfanz <[email-masked]>
Date: Thu, 8 Sep 2011 14:22:34 -0700

> A digest of an OBC would be the CB data for the new CB type.

Yes, exactly! I try to say as much here:
http://www.browserauth.net/channel-bound-cookies (look for my mention of RFC
5929).

> The only downside is that we'd need two additional PK operations for

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

> Note too that what you propose fits RFC 5056 just fine.

Yes, I noticed that, too.

Dirk.

>  We could and

---

From: Nico Williams <[email-masked]>
Date: Thu, 8 Sep 2011 16:32:46 -0500

On Thu, Sep 8, 2011 at 4:22 PM, Dirk Balfanz <[email-masked]> wrote:
> Yes, exactly! I try to say as much
> here: http://www.browserauth.net/channel-bound-cookies (look for my mention
> of RFC 5929).

I did see it :)  Thanks!

> "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 :)

> Yes, I noticed that, too.

Great.

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?

Nico
--