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 --
- [TLS] TLS-OBC proposal Dirk Balfanz
- Re: [TLS] TLS-OBC proposal Anders Rundgren
- Re: [TLS] TLS-OBC proposal Chris Richardson
- Re: [TLS] TLS-OBC proposal Wan-Teh Chang
- Re: [TLS] TLS-OBC proposal Chris Newman
- Re: [TLS] TLS-OBC proposal Dirk Balfanz
- Re: [TLS] TLS-OBC proposal Dirk Balfanz
- Re: [TLS] TLS-OBC proposal Dirk Balfanz
- Re: [TLS] TLS-OBC proposal Nikos Mavrogiannopoulos
- Re: [TLS] TLS-OBC proposal Dirk Balfanz
- Re: [TLS] TLS-OBC proposal Nikos Mavrogiannopoulos
- Re: [TLS] TLS-OBC proposal Anders Rundgren
- Re: [TLS] TLS-OBC proposal Nikos Mavrogiannopoulos
- Re: [TLS] TLS-OBC proposal Anders Rundgren
- Re: [TLS] TLS-OBC proposal Martin Rex
- Re: [TLS] TLS-OBC proposal Nico Williams
- Re: [TLS] TLS-OBC proposal Nico Williams
- Re: [TLS] TLS-OBC proposal Nico Williams