Re: [TLS] TLS-OBC proposal

Nico Williams <nico@cryptonector.com> Wed, 07 September 2011 22:15 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 990EB21F8DFD for <tls@ietfa.amsl.com>; Wed, 7 Sep 2011 15:15:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.775
X-Spam-Level:
X-Spam-Status: No, score=-2.775 tagged_above=-999 required=5 tests=[AWL=-0.798, 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 gkyy21brhhmH for <tls@ietfa.amsl.com>; Wed, 7 Sep 2011 15:15:46 -0700 (PDT)
Received: from homiemail-a24.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id CEC0021F8DD2 for <tls@ietf.org>; Wed, 7 Sep 2011 15:15:45 -0700 (PDT)
Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id AF21D2C806D for <tls@ietf.org>; Wed, 7 Sep 2011 15:17:30 -0700 (PDT)
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; q=dns; s=cryptonector.com; b=IEcu+iOTEzA2NwzAROiC2 r/ezs8yUD8VQebalZ0/PvctAWfQ0BCOUPFZZOcA1WmPuA3QNbhCqMfWEfRlrvRu2 lCcRoTGIpf0Pae/RdcF+Co+mB0k0ZLujx+ifQDD0kbr/ewbWvwn+KWol0mY1ANKW ObM7lXKhFshPHNCvIhJoM4=
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; s=cryptonector.com; bh=+ixgoTRBwwSES4Bs0EMl 5XUp8Q8=; b=YuCQ7ycwxaShjjyPcsfz4VDTZFFX65RCDi1AABCpGVr7aNgPZH6e dgFFzlz2Gepn3t5Jjtr6DCOKH37CldZxzIxOPP4SWXRORuWp2QHqXmfCscn6cSeJ RdXeOvqXujAp4+Zwo1wZJ0469IWZPd1OL6EOWMoPT/6EX4MpHQgdDYA=
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id 813972C806C for <tls@ietf.org>; Wed, 7 Sep 2011 15:17:30 -0700 (PDT)
Received: by vxi29 with SMTP id 29so137042vxi.31 for <tls@ietf.org>; Wed, 07 Sep 2011 15:17:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.116.2 with SMTP id k2mr2101426vcq.74.1315433849948; Wed, 07 Sep 2011 15:17:29 -0700 (PDT)
Received: by 10.220.27.68 with HTTP; Wed, 7 Sep 2011 15:17:29 -0700 (PDT)
In-Reply-To: <CADHfa2AMOeShxH_k5ZEB3DUVJAnOqvZmLMg5Yz8smtBDGkQsNg@mail.gmail.com>
References: <CADHfa2AMOeShxH_k5ZEB3DUVJAnOqvZmLMg5Yz8smtBDGkQsNg@mail.gmail.com>
Date: Wed, 07 Sep 2011 17:17:29 -0500
Message-ID: <CAK3OfOicumMaktE1c0XptERCS1P+oM+Gm73d0TcEFKZWSOVpdw@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: Re: [TLS] 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: Wed, 07 Sep 2011 22:15:46 -0000

I think the cookie hardening aspect of this is the key feature of your
proposal.  Alternatively you'd need a certificate enrollment facility
by which to associate one of these certs with a user account.  Either
way, other user authentication mechanisms are still required (always
at login time w/o cert enrollment, or just at initial cert enrollment
time, but with a more complete key rollover mechanism required to
avoid having to authenticate again at key rollover time.

I'd also note that in all TLS user cert schemes TLS session resumption
(without server-side state) becomes even more important for
performance.

I believe logout is always a difficult problem.  Specifically: proving
to one's peer that state has been torn down is difficult.  But it is
more difficult when logout requires layer crossing.  In this case,
because cookies would still be used for web session identification,
you'd avoid the difficulties of implementing logout in other TLS user
cert applications.  This is good.

The main benefit of binding cookies to user certs rather than server
certs is that cookie leakage is made much less harmful: leaked cookies
would be useful for nothing more than traffic analysis provided that
cookies bear no sensitive information in cleartext.  This is a very
good thing.

Looking at usability, my main concern is that we still need to address
user authentication issues, and/or user cert enrollment and key
rollover.

I'm not a fan of TLS user certs for user authentication: we'll end up
building SACRED-like protocols to deal with the need to use certs from
multiple devices, and so on.  But the HTTP cookie protection aspect of
TLS-OBC is quite enticing.

Nico
--