Subject: [TLS] Making TLS-Client-Certificate-Authentication Useful

From: Anders Rundgren <[email-masked]>
Date: Mon, 08 Oct 2012 14:05:40 +0200

TLS CCA (Client Certificate Authentication) has essentially not been updated in 15 years or so.
Well, the underpinnings have when going from SSL 1.0 to TLS 1.2 but these enhancements were mainly about security, not about usability.

>From a usability point-of-view TLS CCA suffers from many problems when used in browsers including:

- Incompatible with the web session concept which forces you to introduce an IDP even for a single site
- No logout
- Poor credential filtering options

Is the TLS WG aware of these shortcomings?
Is the TLS WG aware of the fact that most consumer PKIs have invented their own application-level PKI-authentication method to circumvent this issues?
Is this what we should expect be the future as well?

thanx,
Anders

---

From: Tom Ritter <[email-masked]>
Date: Mon, 8 Oct 2012 09:58:38 -0400

> Is this what we should expect be the future as well?

As long as websites want to have a state (logged in/not logged in)
that is independent of an underlying transport - I think so.  Keeping
this in mind I think should be foremost.

Origin Bound Certificates (and Channel Bound Cookies) are a way around
that - the Client Certificate does not imply logged in or
not-logged-in.  That state is independent of the client cert.  So in
that case, Client Certs work, and would probably work well.

Likewise, Client Certificates used in POP/IMAP auth work well, because
there is no meaningful 'Logged Out' state in a POP/IMAP conversation.
If I'm connected, I need to be authenticated to receive my mail.

-tom

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 08 Oct 2012 16:17:05 +0200

On 2012-10-08 15:58, Tom Ritter wrote:
> that is independent of an underlying transport - I think so. 

Unfortunately that is not the case.

> Keeping this in mind I think should be foremost.

Yes, but that is special case that is by no means universal.

> If I'm connected, I need to be authenticated to receive my mail.

Yes, I was merely thinking about web servers and browsers.

Anders

---

From: Henry Story <[email-masked]>
Date: Mon, 8 Oct 2012 16:11:47 +0200

> - Incompatible with the web session concept which forces you to introduce an IDP even for a single site

Not sure about this problem.

> - No logout

This is a UI issue. Nothing to do with TLS protocol. Here is a larger discussion with Ben Laurie on the subject recently

> - Poor credential filtering options

+1 yes, that would be useful to have improvements here

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

Social Web Architect
http://bblfish.net/

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 08 Oct 2012 16:33:08 +0200

> Not sure about this problem.

If you have a soft certificate and login to a web-server using HTTPS with client-cert-auth you will
using out-of-the-box solutions remain logged in forever regardless of web-session timeout settings.
My experience here is limited to Servlets.

>> - No logout
> This is a UI issue. Nothing to do with TLS protocol. 
I believe that is a combination of server and *UA* behavior.

> Here is a larger discussion with Ben Laurie on the subject recently

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 8 Oct 2012 08:45:39 -0700

> Is this what we should expect be the future as well?

Without taking a position on whether these are shortcomings or not, I think
people in the  TLS WG are generally aware of the technical behavior of
TLS-based client auth.

My general sense of the situation is as follows:

- There are certain settings in which certificate-based client auth at
the TLS layer
  has been useful, but those settings generally are not the public Web but
  rather things like corporate networks, etc.
- All the evidence suggests that sites want to control their own authentication
  and want to do it in HTML and/or JS not in the transports. Passwords are
  a primitive instance of this, but see also OAuth, Facebook Connect, Persona,
  etc.
- There is a lot of work going on in terms of application-level crypto
   (see WebCrypto, etc.) that seems like a better fit for this model.
- There are a number of advantages to binding the JS/HTML/HTTP auth to the
   transport (OBC is an example of this) but it's probably more useful for
   authentication continuity and state management rather than primary
   authentication.

None of this is to say that TLS client auth couldn't be improved, but
I'd want to
start with a clear use case of what it is for before we started talking about
technical changed.

-Ekr

---

From: Henry Story <[email-masked]>
Date: Mon, 8 Oct 2012 18:56:21 +0200

> My experience here is limited to Servlets.

yes, this is a problem in the client.  The client should log the user out when the user wants
to. This is a problem because the client keeps sending the certificate.

see the e-mail excange with Ben Laurie I linked to below.

> I believe that is a combination of server and *UA* behavior.

The most important problem from the client side is that the clients do now show
how the client is authenticated. If they did then the user would also be able to 
log out in a key stroke.

There is something that can be done at the server layer too, but the biggest issue
is client side. Currently the client sends back the same certificate all the time,
and neither the user nor the server ( except for some javascript in firefox ) can
control the logout elegantly.

>> Here is a larger discussion with Ben Laurie on the subject recently

The mail did not get through due to the attachment exceeding 50k. Here it is in pdf form

http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/privacy-definition-final.pdf

which is easier to read than the the thread

http://lists.w3.org/Archives/Public/public-webid/2012Sep/thread.html

>> +1 yes, that would be useful to have improvements here

To be precise I would like to be able to filter client certificates on some capabilities in the certificate.
For http://webid.info/ all we would need would be a way to ask for certificates with WebID. We can simulate
this with DN, but it would be nice to have something better.

Social Web Architect
http://bblfish.net/

---

From: Henry Story <[email-masked]>
Date: Mon, 8 Oct 2012 19:19:13 +0200

> start with a clear use case of what it is for before we started talking about

I'd disagree with you on your emphasis. In my view the JS crypto is going to be ok as
a fallback for authentication, but TLS is mostly where things need to be. Most 
things JS crypto can do for  authentication would be better done at the TLS layer 
because. TLS is more efficient  - JS is a Turing complete language that is not needed 
for auth. And simpler languages are better and more secure. For robots doing 
authentication on the web, it is a lot  more efficient to have TLS. Even for rich web 
clients one can do everything that is needed declaratively rather than by using JS.  

But people in crypto need to understand the importance of linkability to privacy. Because that
is where the real use serious uses cases are. See 

   http://lists.w3.org/Archives/Public/public-privacy/2012OctDec/0003.html

Henry

Social Web Architect
http://bblfish.net/

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 8 Oct 2012 10:42:38 -0700

On Mon, Oct 8, 2012 at 10:19 AM, Henry Story <[email-masked]> wrote:
> a fallback for authentication, but TLS is mostly where things need to be.

I don't see any evidence that major sites have any interest in this. Quite the
contrary, sites go out of their way to gain control of the authentication
process and that means having it controlled by JS and HTML. I'm neither
endorsing nor condemning this trend, just saying that that's how things
are.

Again, I'd encourage you to describe a set of use cases that demand a change
to TLS and show that there is real interest in them from site operators and the
like.

-Ekr

---

From: Henry Story <[email-masked]>
Date: Mon, 8 Oct 2012 20:03:13 +0200

> endorsing nor condemning this trend, just saying that that's how things

I know but I don't base my thinking on trends. I base it on serious thought
on what the real political ethical privacy issues that need to be solved are.

If you go on trends then in 2007 you'd have said that the boom was going to
keep growing, and you would have lost all your money. You need to look at the
underlying issues. And you'll find as philosophers have often said that the
most constant trend is that if everybody is going one way then it's probably
a dead end they are running into.

In any case the technical issues that stopped people were. 
 1. Too much power for CA -> solved by DANE
 2. no good way to do linkable identity.

> to TLS and show that there is real interest in them from site operators and the

I don't think there is anything actually needing change at the TLS layer.
We can get what we need done, though a nicer certificate selection requests from the 
server ( not just based on DN) would be nice.
 
The rest can be done by combining existing TLS+Linked Data with UI help from browsers.
Look at WebID http://webid.info/ . There is a 10 min video there explainging it.
Also see my talk on the Philosophy of the Social Web at http://bblfish.net/tmp/2010/10/26/ .

In your previous mail you said that TLS client certs are useful for corporate 
networks. That is exactly where you went wrong in selling TLS. And so the real
problem with TLS is not the technology, it's the mind set of those using it, who
fail to notice that they can completely change what is possible by combing TLS's
strenght with the strenght of other technologies.

But I doubt that arguing on a mailing list will make any difference.
I just send a few mails here form time to time, so that those who wish to hear
can hear.

Henry

Social Web Architect
http://bblfish.net/

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 8 Oct 2012 11:05:25 -0700

> I don't think there is anything actually needing change at the TLS layer.

Oh, good. In that case this is off-topic for this mailing list.

-Ekr

---

From: Henry Story <[email-masked]>
Date: Mon, 8 Oct 2012 20:09:20 +0200

> Oh, good. In that case this is off-topic for this mailing list.

It was not off topic for the mailing list, since the other person was arguing there
were changes needed and I was pointing out I disagreed.

Gee the way some IETF people love to throw things off topic that makes them
question their assumptions is seriously tedious.

Anyway, I did point to one change that would be nice:
  A way for the server to more finely select certificates not based just 
on DNs.

As far as we are concerned we can get around a lot of issues with TLS, because
arguing one to one on these lists is just not a good use of one's time.

Henry

Social Web Architect
http://bblfish.net/

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 8 Oct 2012 11:18:38 -0700

> were changes needed and I was pointing out I disagreed.

Fine, but the rest of your post is irrelevant.

> question their assumptions is seriously tedious.

Perhaps if you made more effort to avoid spamming mailing lists
with off-topic content you would find people did not tell you that
it was off-topic.

>   A way for the server to more finely select certificates not based just

Fine, now we're back to being to the topic of this list. A better way
of expressing
the server's preferences about which certificate the client should supply would
certainly be in scope. I would encourage you to publish a draft describing
the relevant use cases and (perhaps) a proposed mechanism.

-Ekr

---

From: Henry Story <[email-masked]>
Date: Mon, 8 Oct 2012 20:24:30 +0200

> with off-topic content you would find people did not tell you that

I am not spamming mailing lists. Btw. I hope you know the 
ethical imperative that you cannot create moral law that is not
also applicable to yourself. Let us see how you stand up to your
own criteria:

>  rather things like corporate networks, etc.

Wrong. IT can be used for wider internet. 

>  a primitive instance of this, but see also OAuth, Facebook Connect, Persona,

Is this not all off-topic? What has your (mistaken) idea of JS, OAUth etc
to do with TLS.

>   (see WebCrypto, etc.) that seems like a better fit for this model.

Btw. I am fore WebCrypto, but this is off topic no?

>   authentication continuity and state management rather than primary

And again wrong. See WebID for a counterexample.

Social Web Architect
http://bblfish.net/

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 8 Oct 2012 11:30:21 -0700

Henry,

There's a difference between explaining that a proposed change to
layer A isn't likely to take off because people want to solve the problem
at layer B and simple off-topic ranting. I'm sorry you can't see this.

-Ekr

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 08 Oct 2012 21:02:25 +0200

> at layer B and simple off-topic ranting. I'm sorry you can't see this.

I guess this concludes my view on this topic.  It is so infected that
we better move on and leave TLS CCA to the only application where it
actually works, that is, creating secure tunnels between boxes.

Anders

---

From: Yoav Nir <[email-masked]>
Date: Tue, 9 Oct 2012 07:38:37 +0200

> Oh, good. In that case this is off-topic for this mailing list.

<plug type="shameless">

There may be another mailing list where this may be on-topic: the http-auth mailing list [1]. That one is concerned with authentication at the HTTP layer. There's also a BoF planned for Atlanta.

Note that the kind of auth discussed there is not in HTML or JS either, so plugging WebID is not really appropriate there either. However, well-supported arguments why HTTP is the wrong layer for authentication *are* appropriate for that list. Also, discussion of the UI requirements for authentication are very appropriate both on that list and at the BoF, because modifying browsers to allow customization of the authentication dialog is possible in HTTP (and HTML), but would be very strange in TLS.

If you believe you have UI expertise, and would like to discuss it in the Atlanta BoF, please contact Derek Atkins or me directly. 

</plug>

Apologies for hijacking this thread for plugging our BoF. I promise to do this only this once (at least on this mailing list)

Yoav

[1] https://www.ietf.org/mailman/listinfo/http-auth

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 09 Oct 2012 09:45:01 +0200

> Apologies for hijacking this thread for plugging our BoF. I promise to do this only this once (at least on this mailing list)

Any effort trying to make TLS CCA more useful is most welcome!

Anders