Re: [TLS] TLS-OBC proposal

Dirk Balfanz <balfanz@google.com> Thu, 25 August 2011 06:01 UTC

Return-Path: <balfanz@google.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 2366721F8A69 for <tls@ietfa.amsl.com>; Wed, 24 Aug 2011 23:01:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.976
X-Spam-Level:
X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 ok6zwZhSgW6y for <tls@ietfa.amsl.com>; Wed, 24 Aug 2011 23:01:29 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8602A21F8A91 for <tls@ietf.org>; Wed, 24 Aug 2011 23:01:29 -0700 (PDT)
Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id p7P62fkV004253 for <tls@ietf.org>; Wed, 24 Aug 2011 23:02:41 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314252161; bh=n7ogM1KHdHqAw8IbDbqpEuyxEQo=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=YW44eNrg71WuyTGrT1HZfw23n333mio8Ti0AcqXWpRVvtZLTaGiwU00XDi1IiLfue MFVeyWzamVLAzamd6F7rQ==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=PDu/gCnI2wVu+GhDyPSFkVonBaVrehaomdKp0v8A43flpbmnv8CxnD/OrR1UCHjtm Xc3rkhh02EAhPRTlq3mRg==
Received: from gyg4 (gyg4.prod.google.com [10.243.50.132]) by hpaq3.eem.corp.google.com with ESMTP id p7P627vM006943 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <tls@ietf.org>; Wed, 24 Aug 2011 23:02:40 -0700
Received: by gyg4 with SMTP id 4so1842122gyg.34 for <tls@ietf.org>; Wed, 24 Aug 2011 23:02:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sv9+BNbqTSbh8r+oxapxaSAhuIOtWQmBsPRr9j1jE3k=; b=xWSKtGxB040vaqtevagMUkgDR2QU6ZXgUwD2ofS59eR9wkFBkJX99OOWa55UHLctbX ZnBJSXsrVbCDT9D5EoRg==
Received: by 10.91.3.3 with SMTP id f3mr5823526agi.71.1314252159601; Wed, 24 Aug 2011 23:02:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.91.3.3 with SMTP id f3mr5823516agi.71.1314252159224; Wed, 24 Aug 2011 23:02:39 -0700 (PDT)
Received: by 10.90.56.4 with HTTP; Wed, 24 Aug 2011 23:02:39 -0700 (PDT)
In-Reply-To: <4E52ACCC.20303@telia.com>
References: <CADHfa2AMOeShxH_k5ZEB3DUVJAnOqvZmLMg5Yz8smtBDGkQsNg@mail.gmail.com> <4E52ACCC.20303@telia.com>
Date: Wed, 24 Aug 2011 23:02:39 -0700
Message-ID: <CADHfa2As50Q5ShRE-uxEi-nnsmb5TS-JYgzzmHsOP-iHdpK_SA@mail.gmail.com>
From: Dirk Balfanz <balfanz@google.com>
To: Anders Rundgren <anders.rundgren@telia.com>
Content-Type: multipart/alternative; boundary="0016363b8084188a9804ab4e2df8"
X-System-Of-Record: true
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: Thu, 25 Aug 2011 06:01:31 -0000

On Mon, Aug 22, 2011 at 12:23 PM, Anders Rundgren <anders.rundgren@telia.com
> wrote:

> Hi Dirk,
>
> I have not yet completely understood what you are trying to do but one
> thing that we seen to agree on is that HTTPS CCA (Client Cert
> Authentication)
> is [more or less] useless.  That's at least a start :-)
>
> I don't know if you have followed the somewhat wild discussion I started
> a while on this list where I asked for a "logout"?
>

No sorry I missed those!

But speaking of logout - with TLS-OBC and channel-bound cookies, logout is
easy: you do it just like you do it today: by overriding or expiring the
cookie you set when you "logged in" the user.


>
> FWIW, I can attest hat banks in the EU and Asia on a *massive scale* have
> replaced the HTTPS-CCA with application-level CCA using home-brewed
> plugins.
>
> I'm a little hesitant (from a deployment point-of-view) about mucking
> around in the TLS layer.  Wouldn't it be possible to achieve this
> anyway web-only functionality with more "webbish" methods?  Not as
> clean but it would probably be easier rolling out.
>

I made a few attempts at doing this on the application and HTTP layers -
they didn't really work out. One problem is security: if we look at
integrity, for example, TLS gives us that for free. To recreate that, say,
at the HTTP layer, we'd have to invent some form of signature on the HTTP
request. So immediately the question is: how much of the request do you
sign? Do you sign the all headers? The POST body? If you sign the whole POST
body, then you can't generate the signature until you've seen the whole POST
body. What if the POST body is a multi-gigabyte video? And if the signature
goes into the HTTP headers, which must come _before_ the POST body, this
means you have read the whole POST body for signing it, and then read it
again to pump it out to the network (assuming it's so big that it doesn't
fit into whatever buffer you have).

Another problem was performance: Signing every single HTTP request with an
asymmetric key seems like overkill. So somehow, the server and client would
have to negotiate an HMAC key that would be used to sign HTTP requests. That
HMAC key would probably be visible to the attacker (which we assume sits in
the browser). To decrease the benefit that the attacker has from seeing the
HMAC key, we would re-negotiate a new HMAC key every so often, with the
client having to re-prove that it is in possession of its private key (we
assume that the attacker can't get to the private key, since that can sit in
a TPM). It's hard to imagine how to do that on the HTTP or application layer
without introducing a roundtrip between client and server that establishes
that new HMAC key. While that roundtrip is happening, you can't make other
calls to the server (well, you can make 3 others or so depending on how many
simultaneous HTTP connections your browser allows with a server, but the
point is that you're using one of your limited number of TCP channels for
this key renegotiation). In TLS, we have a similar problem - the session
master secret might be known to the attacker, so every now and then we'd
like to reset it by renegotiating the TLS session. In TLS, however, we can
interleave data and handshake messages, so renegotiating the session secret
doesn't mean that we're holding up a whole TCP connection.

These (and a couple of other) nice features that TLS gives us for free we
would end up "reinventing" on the HTTP or application layers, up to the
point where we would have reinvented almost all of TLS.

Dirk.

P.S. I should also mention that doing this on the application layer (i.e.,
TLS doesn't know about this, HTTP doesn't know about this, but the
client-side and server-side libraries we use to write our apps would provide
the necessary functionality) also would have meant that apps would have to
be substantially re-written, which we thought was a show-stopper. So the
only serious contender was to do this at the HTTP layer.



> Anders
>
> On 2011-08-22 19:53, Dirk Balfanz wrote:
> > Dear TLS-WG,
> >
> > I few weeks ago I presented a proposal for an "origin-bound certificates"
> TLS extension at IETF 81. It's much easier to understand what this extension
> is trying to accomplish when presented in a
> > broader context of web authentication (which I tried to give in Quebec),
> so I put together a little web site that is supposed to do just that for
> those who couldn't be at the IETF meeting:
> > http://browserauth.net (This took me a little while, hence the delay in
> sending out the I-D).
> >
> > Anyway, here is the I-D:
> http://tools.ietf.org/html/draft-balfanz-tls-obc, which I submit for your
> comments/feedback. (Again, remember to read http://browserauth.net for
> some context.)
> >
> > All feedback is welcome, of course, but if you can't think of anything to
> comment on, I have a couple particular questions:
> >
> > - in Section 2.1.1 we currently stipulate that the client include the
> origin of the origin-bound cert as part of the OBC X.509 extension. When we
> implemented this, we didn't really know what to do
> > with that data on the server side. If the client also uses TLS-SNI, then
> we could imagine comparing the SNI and OBC origins in some manner on the
> server side, but there isn't really a vehicle to
> > signal an error back to the client saying "your SNI and OBC origins don't
> match". Similarly, we could perhaps at some higher layer compare the HTTP
> "Host" header with the OBC origin, but then again -
> > what do you do when they don't match? Respond with a 400 at the HTTP
> layer? An alternative to the current language in the I-D would be to simply
> mark the cert as origin-bound, but without putting the
> > origin itself into the cert. Any thoughts?
> >
> > - What do you think of the privacy-enhancing power of using per-origin
> certs? The idea there is that different domains see different "identities"
> (public keys) for the same client. Of course, if two
> > domains choose to collaborate, they can probably find a way to correlate
> the two identities they see for the same client. This is similar to cookies,
> where normally "identities" (cookies) for one
> > domain are not revealed to another domain unless, of course, they choose
> to collaborate. How much privacy would we really lose if we just used one
> certificate for all origins? It would certainly make
> > the design and implementation simpler. (I tend to favor per-origin certs,
> but I'm curious as to what other people think.)
> >
> > Thanks for your consideration!
> >
> > Dirk.
> >
> >
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
>