Re: [TLS] TLS-OBC proposal

[Dirk Balfanz <[e-mail]>]

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

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

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.



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