Subject: Re: [TLS] TLS-OBC proposal

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 01 Sep 2011 13:51:08 +0200

On 08/22/2011 07:53 PM, 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).
[...]
> All feedback is welcome, of course, but if you can't think of anything to
> comment on, I have a couple particular questions:

I like the proposal. As far as I understand you try to fix the usability 
problem of using multiple certificates for different sites. This is 
similar to an SSH-style authentication for users. As a side-effect 
pseudonymity can be achieved. Some minor comments.

* In http://www.browserauth.net/tls-client-authentication you mention 
the inability to log-out as one reason that TLS client authentication 
fails. However this is not addressed by OBC if I understand correctly. 
(to be honest I think that the inability to log-out is just a UI 
problem. TLS authentication does not need to imply log-in. You might 
have buttons login and logout that will log the user in and out even if 
TLS with authentication was used)

* Why you require a critical X.509 extension for that? (I also don't 
like the IA5String... why not UTF8?)

* After having read the proposal the name OBC was clear to me. However 
before reading it, the name didn't give any clue (to me) of the proposal.

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

I'd send a TLS alert or do nothing. What does this check add?

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

I don't like having the origin in the certificate as a critical extension.

regards,
Nikos

---

From: Dirk Balfanz <[email-masked]>
Date: Fri, 2 Sep 2011 10:21:34 -0700

On Thu, Sep 1, 2011 at 4:51 AM, Nikos Mavrogiannopoulos <[email-masked]>wrote:

> problem of using multiple certificates for different sites. This is similar
> to an SSH-style authentication for users. As a side-effect pseudonymity can
> be achieved. Some minor comments.
>
> * In http://www.browserauth.net/**tls-client-authentication<http://www.browserauth.net/tls-client-authentication>you mention the inability to log-out as one reason that TLS client
> authentication fails. However this is not addressed by OBC if I understand
> correctly. (to be honest I think that the inability to log-out is just a UI
> problem. TLS authentication does not need to imply log-in. You might have
> buttons login and logout that will log the user in and out even if TLS with
> authentication was used)
>

The site where I wrote the documentation - browserauth.net - is an example
for this. There is a sign-in link at the bottom of each page. Are you saying
that with TLS Client Auth, the server would require a certificate from the
client, and the user would have to decide upfront whether or not to supply a
certificate. Then, when the user gives no certificate or a "wrong"
certificate, there would be no sign-in link on the site (but it would still
render), but when the "right" certificate is given by the user, then the
server would give the user a sign-in link on the page? At that point, the
sign-in link isn't really about signing in. It's more a "you already know
who I am, please give me some edit controls on this page"-link. Also, note
that the user had to decide whether or not to provide a certificate before
they saw the page.

With TLS-OBC, you have the normal cookie model. The first time you go to the
site, you have no cookies. It's up to the server to decide whether or not it
can give you a meaningful UI in that case (browserauth.net decides that it
can). Then, when it's time to reveal to the server who you are, you click on
the sign-in link, and eventually end up with a cookie that you send to the
server, which will allow it to identify you, and draw a "logged-in" state
UI.

I totally agree that this a UI issue - a pretty subtle one. But I think that
TLS Client Auth will dictate a different UI from what we're used to today,
whereas TLS-OBC with cookies will allow us to stick to the same UIs we have
today.

>
> * Why you require a critical X.509 extension for that? (I also don't like
> the IA5String... why not UTF8?)
>

The critical extension is there so that these certificates can't be used out
of context. For example, we require the server to check that the extension
is there, or else reject the certificate. We should fix the IA5String. I
forget why we picked that - I think it was something like Adam Barth's web
origin spec not defining a UTF8 serialization of web origins when we wrote
our draft or something like that. I agree it should allow unicode.

A separate question is whether that string (the origin) should be in the
cert to begin with. I take it that your inclination would be to not include
it, which is what I'm also considering now.

Dirk.

> ______________________________**_________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/tls<https://www.ietf.org/mailman/listinfo/tls>
>

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sun, 04 Sep 2011 14:43:14 +0200

> whereas TLS-OBC with cookies will allow us to stick to the same UIs we have

Indeed, but you still use client certificate authentication. The 
difference is that there is no trusted party certifying the client's 
name and the 1-1 mapping to certificates with sites.

> is there, or else reject the certificate.
[...]
> it, which is what I'm also considering now.

I find your point above quite interesting (preventing (re)use in 
different contexts). It might be worth keeping it.

regards,
Nikos

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 04 Sep 2011 18:42:47 +0200

I have probably not understood the TLS-OBC proposal but one part
spurred my interest and that was that apparently (?) an application
eventually ends-up with a session cookie rather than the horrible
(at least from a web context seen... ), TLS session scheme.

If this assumption is correct, I think it would be a pity "patching"
the HTTPS protocol without being able to also use the above with
traditional client-certificates.  In fact, I think this proposal will
go pretty much nowhere unless it does.

If I OTOH have go the session-stuff wrong, please just ignore my
ignorant comments.  FWIW, I have developed an app-level CCA
(Client-Certificate Authentication) mechanism derived from the
numerous proprietary solutions out there. 

http://code.google.com/p/openkeystore/source/browse/trunk/library/src/org/webpki/wasp/webauth.xsd

If you come up with a generic solution, I will gladly retire it!

Traditional TLS-CCA sucks, and logout is by no means
"a subtle UI problem"; it goes to the core.

Anders

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sun, 04 Sep 2011 19:32:20 +0200

On 09/04/2011 06:42 PM, Anders Rundgren wrote:

> Traditional TLS-CCA sucks, and logout is by no means "a subtle UI
> problem"; it goes to the core.

The problem is layer mixing. I believe you understand that TLS
authentication is about authentication of the TLS session and not the
HTTP session which is on a layer above. If you naively use the TLS
authentication for HTTP authentication you have the issues current
applications face. TLS-OBC as I understand it, ties better the HTTP and
TLS certificate authentication to prevent the issues currently seen. The
advantage is that it re-uses the existing mechanisms.

I cannot read your approach in the xml file, but I understand that you
moved authentication to the application layer. This is an alternative
approach.

regards,
Nikos

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 04 Sep 2011 21:31:18 +0200

Nikos,
Maybe I was a bit unclear.

I'm not suggesting mine or the gazillion of similar solutions
as an alternative to TLS-OBC since they address entirely different
markets.

However, I'm asking if an enhanced TLS-OBC could replace them by
increasing the scope of the proposal.  I'm not enough of a expert
in TLS too see if it is possible or a good idea, I just want to
point out that there is a great need for a better HTTPS CCA.
Otherwise the mentioned solutions would not exist.

In fact, I believe there may be more users of app-level HTTPS CCA
than there users of "genuine" HTTPS CCA.

Regards,
Anders

.
On 2011-09-04 19:32, Nikos Mavrogiannopoulos wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Nico Williams <[email-masked]>
Date: Wed, 7 Sep 2011 16:54:57 -0500

On Mon, Aug 22, 2011 at 2:23 PM, Anders Rundgren
<[email-masked]> wrote:
> 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'm certainly a fan of webbish methods, as you put it.  For an example
of this see http://tools.ietf.org/html/draft-williams-rest-gss-00

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 7 Sep 2011 17:17:29 -0500

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

---

From: Nico Williams <[email-masked]>
Date: Wed, 7 Sep 2011 17:19:28 -0500

> cookies bear no sensitive information in cleartext.  This is a very

I should add that binding in some server (site, really) identification
information is also important, as a hedge against the risk that a
client might reuse one of these self-signed certs with other servers!

Nico
--