Subject: [TLS] concers about draft-balfanz-tls-obc

From: [email-masked]
Date: Fri, 18 Nov 2011 17:10:08 +0800

Hi,
   I don't think the origin-bound-certificate is meaningful.
   The reasons are:
   1. CA signed client certificate is used to authenticate the client 
user, now it is replaced by a self-signed certificate, how can a server 
trust or authenticate a self confirmed user?
   2. If client authentication is not required, then there is neither need 
to send a self-signed certificate.
   3. To the goal of bindling cookie with self-signed certificate, the 
ordinary CA signed certificates also work.

Sujing Zhou

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 18 Nov 2011 10:19:21 +0100

On Fri, Nov 18, 2011 at 10:10 AM,  <[email-masked]> wrote:
>    1. CA signed client certificate is used to authenticate the client user,
> now it is replaced by a self-signed certificate, how can a server trust or
> authenticate a self confirmed user?

Isn't it the current situation in web sites? Aren't all popular web
site's users self confirmed?

> to send a self-signed certificate.

I don't think that the draft asks for client to be authenticated when
client authentication is not required.

> ordinary CA signed certificates also work.

At a cost that no-one is willing to pay (not only monetary, but also
the cost of proving yourself to the CA --or the CA will allow
self-confirmation to the users? :).

regards,
Nikos

---

From: [email-masked]
Date: Fri, 18 Nov 2011 17:43:51 +0800

> >    1. CA signed client certificate is used to authenticate the client 
user,
> site's users self confirmed?

Not in the case of bank website.
the certificate may be signed by the bank but defntly not by the client 
user self.

---

From: Nico Williams <[email-masked]>
Date: Fri, 18 Nov 2011 16:34:57 -0600

> authenticate a self confirmed user?

It doesn't matter how the user is initially authenticated (password
POSTed in forms, user certs, doesn't matter).  As for the server, it
will only inspect the OBC in order to verify that it is the
certificate to which the cookies are bound.

> to send a self-signed certificate.

Client authentication is orthogonal to OBC.

OBC protects the session cookies from theft.  Let's say you steal my
session cookies somehow (e.g., via the BEAST attack): but if you don't
have my OBCs' private keys then you can't actually make use of my
cookies.

With OBC cookie theft is not enough.  With OBC the attacker must get
at the private keys for the OBCs.

Also, with OBC you get closer to true logout: destroy ("forget") your
OBC private keys and your sessions are as good as dead.  Moreover, the
user-agent, not the server, is in control of maximum session lifetime,
since there's no point in the server setting cookies that will outlive
the OBCs.  (The server can set cookie lifetimes shorter than OBC
lifetimes, of course, but not longer, and that's what's valuable here
to the user-agent.)

> ordinary CA signed certificates also work.

<snark>True, and the three users with commercial CA-issued
certificates will not be affected.</snark>

The non-snarky answer to this is above, in answer to (1).

********

Now, I've observed before, and will repeat here, that we could have a
cookie-to-TLS-session cryptographic binding that doesn't require the
use of any user certificates at all.  But in the end the effect would
be the same as with OBC, and the protocol design trade-offs in the two
approaches are are such that OBC is probably the path of least
resistance (specifically, binding to TLS sessions would effectively
require session resumption without server-side state to be widely
deployed).

Therefore I am a fan of OBC.  I expect OBC to happen, and it will
improve web security significantly.

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Sat, 19 Nov 2011 13:15:32 +0200

On Nov 18, 2011, at 11:34 PM, Nico Williams wrote:
> the OBCs. 

I we can find no other use case, we might want to rename it to "Origin Bound Cookie".

But that would require some interesting interaction between layers. 

Are all cookies received while using OBC considered (by the client!) bound to the OBC? If not, the client might use an old cookie after a logout event, leading to the server falsely detecting an attempt to forge a cookie. Maybe we need a new keyword on the cookie header.

Where is the "logout" button?  If it's part of the website (in the "canvas") how does the HTML/HTTP tell the browser to log out? Probably best to have it in the Chrome for sites where OBC are supported.

---

From: Nico Williams <[email-masked]>
Date: Sat, 19 Nov 2011 13:03:25 -0600

> I we can find no other use case, we might want to rename it to "Origin Bound Cookie".

The cookies are not bound to origins.  They are bound to -effectively-
sessions (I don't mean TLS sessions strictly speaking).

So if you want to take "certificates" out of the name you'd have to
take "origin" out also.

> But that would require some interesting interaction between layers.

OBC requires interaction between layers: the layer that sets and
validates cookies must interact with the TLS layer.

> Are all cookies received while using OBC considered (by the
> client!) bound to the OBC? If not, the client might use an old

The client has no way to verify the cookie bindings.  Only the server
can do that.

The client has the power to make the cookie bindings (when they are
bound) impossible to verify.

> cookie after a logout event, leading to the server falsely
> detecting an attempt to forge a cookie. Maybe we need a
> new keyword on the cookie header.

We may want -but don't strictly- need a way for servers to tell
clients which cookies are bound and which aren't.  The client can, of
course, apply some heuristics, such as "secure-only cookies where the
server supports OBC and we used OBC must be bound" and "all other
cookies can't be bound or the binding isn't critical to the server".

> Where is the "logout" button?  If it's part of the website (in the "canvas") how does the HTML/HTTP tell the browser to log out? Probably best to have it in the Chrome for sites where OBC are suppo…

This needs more elaboration, clearly.  What I said was that the client
can enforce a logout (well, when the server really wants valid bound
cookies).  A logout that involves both, the client and the server will
require some protocol work, but that wouldn't be strictly necessary
(we manage today...).

Nico
--