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

Nico Williams <nico@cryptonector.com> Thu, 08 September 2011 19:46 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 94A4D21F8744 for <tls@ietfa.amsl.com>; Thu, 8 Sep 2011 12:46:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.707
X-Spam-Level:
X-Spam-Status: No, score=-2.707 tagged_above=-999 required=5 tests=[AWL=-0.730, 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 oWyd+zs7ZkdE for <tls@ietfa.amsl.com>; Thu, 8 Sep 2011 12:46:37 -0700 (PDT)
Received: from homiemail-a31.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 157F021F873A for <tls@ietf.org>; Thu, 8 Sep 2011 12:46:36 -0700 (PDT)
Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 1B5D4202038 for <tls@ietf.org>; Thu, 8 Sep 2011 12:48:12 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :date:message-id:subject:from:to:cc:content-type; q=dns; s= cryptonector.com; b=jiP8BG/UWEQHBPmAzM+gC2mEi/fpBlw1xKUD+B4HiUZ8 mSPdEs5UlMW8eG3GClnu/9xCwBBiJxVpFIbIWUKj+RsN/8m0+oy+GYJF4GdO0rqh HDoNhwHdXTCEXtOmwdDmTg74HSm+ogrZyuG3B5lFiQfxrNByBhfCJHrgGsTtkAs=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type; s= cryptonector.com; bh=CbJbp7EV2XWF6CIDjgejMWp0Q8c=; b=hf4DftFaywg vkv03J4SQ0af6rB8HFFa5LGqkjXHGeFX3sbbWZehmS9hAFIqDoi60qirAKt1Eu79 iE/nXwd4joiwif+Er2jZ0M4HDSXBx82ys8caCPXp7yttDaeJsezimdrCyvKoKLp9 uT3tqYMzoPJi8MEzJFp97jGTyNY6n8Aw=
Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id C4EDF20203C for <tls@ietf.org>; Thu, 8 Sep 2011 12:47:49 -0700 (PDT)
Received: by pzk33 with SMTP id 33so5552644pzk.18 for <tls@ietf.org>; Thu, 08 Sep 2011 12:47:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.0.34 with SMTP id 2mr1670872pbb.399.1315511269302; Thu, 08 Sep 2011 12:47:49 -0700 (PDT)
Received: by 10.68.66.163 with HTTP; Thu, 8 Sep 2011 12:47:49 -0700 (PDT)
Date: Thu, 8 Sep 2011 14:47:49 -0500
Message-ID: <CAK3OfOi4p9fYgODZG6mn0u3YdZb_Nzh0_dZ0fDiGJYRRjVqi7g@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Dirk Balfanz <balfanz@google.com>
Content-Type: text/plain; charset=UTF-8
Cc: tls@ietf.org
Subject: [TLS] TLS-OBC and channel-bound cookies as a new TLS CB type (Re: TLS-OBC proposal)
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: Thu, 08 Sep 2011 19:46:37 -0000

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