Subject: [TLS] TLS-OBC proposal

From: Dirk Balfanz <[email-masked]>
Date: Mon, 22 Aug 2011 10:53:05 -0700

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.

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 22 Aug 2011 21:23:56 +0200

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

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.

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.)
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Chris Richardson <[email-masked]>
Date: Tue, 23 Aug 2011 19:25:26 -0400

I think the draft is inconsistent with respect to the
certificate_authorities list.

>From section 3.3: "[if both sides include the extension], client and
server are considered to have negotiated origin-bound client
certificates for the session."

No problem there.

>From section 3.4: "the server MAY use an empty "certificate_authorities" list"

Should that be a MUST, or at least a SHOULD?  If OBC has been
negotiated, why would a CA-signed cert be used?

>From section 3.4: [the client] MUST ignore the "certificate_authorities" list

No problem there, but it again makes me think the server SHOULD/MUST
send an empty list.

Section 3.5: If the "certificate_authorities" list in the Certificate
Request is empty, that certificate SHOULD be an origin-bound
certificate, and it should be selected by the client without any
assistance or approval by the end-user. If the
"certificate_authorities" list in the Certificate Request is not
empty, the client MAY select a regular certificate for inclusion in
the Client Certificate message, and MAY involve the end-user in the
certificate selection process."

The client MUST ignore the list, but MAY take action based upon the
content of the list?

Chris

On Mon, Aug 22, 2011 at 1:53 PM, Dirk Balfanz <[email-masked]> 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).
> - 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.)

---

From: Wan-Teh Chang <[email-masked]>
Date: Tue, 23 Aug 2011 16:39:18 -0700

> clean but it would probably be easier rolling out.

The reason the origin-bound certificates are used in TLS client
authentication is to save one round trip.  Otherwise the server will
need to send a challenge for the client to sign.

There is a variant where the client signs a shared value derived from
the TLS master secret, to avoid the need for the server to send a
challenge.  That variant can be used at the HTTP layer when running
over TLS.

Wan-Teh

---

From: Chris Newman <[email-masked]>
Date: Tue, 23 Aug 2011 21:58:10 -0700

TLS client certificate authentication is used sometimes with email. Indeed 
it's a significant reason this draft is needed: 
draft-melnikov-pop3-over-tls-01.txt.

Some mail clients associate a single TLS client certificate with a "mail 
account" and would not benefit from OBC. Some mail clients store TLS client 
certificates in a pool and one has to be selected for a given account when 
the server requests a client certificate. Such mail clients would benefit 
from OBC. However, the two most widely deployed open source TLS stacks 
(OpenSSL & NSS) are changing very slowly. I'm skeptical that OBC provides 
enough benefit to actually get implemented and deployed in such TLS stacks. 
Do you know of implementers sufficiently interested in the feature that 
they would be willing to contribute code to OpenSSL and NSS?

		- Chris

--On August 22, 2011 10:53:05 -0700 Dirk Balfanz <[email-masked]> wrote:

> 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).
>
> - 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
> "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

---

From: Dirk Balfanz <[email-masked]>
Date: Wed, 24 Aug 2011 23:02:39 -0700

On Mon, Aug 22, 2011 at 12:23 PM, Anders Rundgren <[email-masked]
> wrote:

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

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

> 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:
> > 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.)
> >
> 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
> mark the cert as origin-bound, but without putting the
> (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.)
> >

---

From: Dirk Balfanz <[email-masked]>
Date: Wed, 24 Aug 2011 23:22:25 -0700

> negotiated, why would a CA-signed cert be used?

Agreed. I'll fix it. Probably a SHOULD, just in case some servers find it
hard to turn off their standard list of CAs?

> The client MUST ignore the list, but MAY take action based upon the

Good catch - you're seeing a bad merge of two different versions of this
section. The one I meant to be in there is the one where the client MUST
ignore the list (long story...:-).

I'll collect more comments for now (instead of fixing it right away), but I
will make sure that gets fixed in the next draft.

Dirk.

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

---

From: Dirk Balfanz <[email-masked]>
Date: Wed, 24 Aug 2011 23:31:20 -0700

On Tue, Aug 23, 2011 at 9:58 PM, Chris Newman <[email-masked]>wrote:

> draft-melnikov-pop3-over-tls-**01.txt.
>
> Do you know of implementers sufficiently interested in the feature that they
> would be willing to contribute code to OpenSSL and NSS?
>

As a proof-of-concept, we're putting support for TLS-OBC both into OpenSSL
and NSS. Whether that will ever land in the main branches depends on whether
our proof-of-concept is successful (demonstrates acceptable utility and
performance), and I guess also to a degree on whether groups like this one
find the proposal worthwhile. As you point out, there is a bit of a
chicken-and-egg problem going on here, but we _are_ writing the code for
this as we speak both for OpenSSL and NSS.

Dirk.

>> Anyway, here is the I-D: http://tools.ietf.org/html/**
>> draft-balfanz-tls-obc <http://tools.ietf.org/html/draft-balfanz-tls-obc>,