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

[Nico Williams <[e-mail]>]

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