Re: [TLS] TLS-OBC proposal

[Chris Newman <[e-mail]>]

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 <[e-mail]> 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.
>