Re: TLS-CCA. Was: Browser UI & privacy - a discussion with Ben Laurie

On Oct 8, 2012, at 10:57 AM, Nathan wrote:

> Ron Garret wrote:
>> On Oct 8, 2012, at 10:07 AM, Nathan wrote:
>>> Ron Garret wrote:
>>>> On Oct 5, 2012, at 11:49 PM, Melvin Carvalho wrote:
>>>>> On 6 October 2012 08:16, Anders Rundgren <anders.rundgren@telia.com> wrote:
>>>>> On 2012-10-05 20:47, Henry Story wrote:
>>>>> 
>>>>>>> WebCrypto could very well become a better mousetrap than TLS CCA.
>>>>>> By WebCrypto you mean using javascript. That does not really change anything.
>>>>> It does because it liberates WebID from a scheme (TLS CCA) that in its current
>>>>> form is doomed as a consumer solution.
>>>>> 
>>>>> TLS CCA is actually quite popular and useful for creating secure tunnels between
>>>>> servers.  However, as a web solution for end-users TLS CCA has essentially not
>>>>> taken a single step forward since 1996!  Well, the "underpinnings" have changed
>>>>> considerably but that doesn't help much since its "behavior" remains neanderthalish.
>>>>> The latter is presumably "by design".
>>>>> 
>>>>> I'm surprised that you find the current key generation mechanisms useful.  No major
>>>>> user of consumer-PKI I have heard of actually use them.  "<keygen>" as featured in
>>>>> Chrome was also designed in the 90'ties.  This is a very touchy issue since
>>>>> 
>>>>>  http://www.ietf.org/mail-archive/web/pkix/current/msg31241.html
>>>>> 
>>>>> caused the PKIX chairs to remove me from the list!
>>>>> 
>>>>> Anders, did you ever look at this?
>>>>> 
>>>>> http://lists.w3.org/Archives/Public/public-xg-webid/2011May/0047.html
>>>>> 
>>>>> A full javascript solution to WebID including crypto libraries.
>>>>> 
>>>>> May be interesting to this group.
>>>> As long as Forge has entered the conversation I would also like to point to my own identity project:
>>>> http://dswi.net/
>>>> DSSID uses Forge for its crypto, but it uses a different protocol specifically designed to be simple for clients to integrate with.  Note: this code is not ready for production use.  Feedback and comments are welcome.
>>> You could decentralize it and make it stateless by:
>>> a) using a URI for a UID (which could point to the clients public key)
>> Yes, the long-term plan for DSSID is to make it decentralized in exactly this way.  The reason for keeping things centralized for now is that current browsers don't have any place to store the key that is accessible across domains.  And this is a good thing because otherwise it would be nearly impossible to secure the key.  To implement a DSSID-like protocol that is both decentralized and secure will require some new browser support for securely storing keys.
> 
> Hopefully the Web Crypto API work will solve that problem.

Indeed.

>>> b) removing sessions (makes it stateless)
>> The DSSID protocol is stateless.  What made you think it wasn't?
> 
> Inferred it by multiple uses of the word session, and terms like "logging in", and an inference that authenticating was a one time action per domain / application.

Ah.  Well, that is up to the RP.  Authenticating with DSSID typically *is* a one-time action, and the RP will typically give the user a cookie.  So in the "preferred embodiment" there is state, but that state resides in the RP, not in the DSSID protocol.  You could use the DSSID protocol to authenticate on every transaction, but that would be very awkward with the current UI.  It would not be hard to add a feature that would allow user-interaction-free authentication on every server interaction, but I don't really see what the advantage would be.

>>> c) swapping nonce for the URI of the resource being requested (ensures user holds private key)
>> That won't work.  The nonce is required in order to protect against replay attacks.
> 
> Where replay attack protection is needed, generally one may want to use a keypair like a one time password.

I don't understand this at all.  How exactly would you use a keypair as a OTP without a nonce?

> 
>>> you could also:
>>> e) have optional origin bound keys
>> Yes, that is possible, but it would undermine the central premise of DSSID which is that your key is your identity.  A user could *choose* to have different keys for different sites, but should not be forced to.
> 
> Hence I suggest loosing that premise. As a user I may want to have a different key, per origin, per device. For example if facebook were to migrate to this, then I may want to log in and get a key passed to my browser for local storage which identifies me on that browser. Then another for my mobile, another for my tablet, and another for a different browser. If I then swap PCs, loose my mobile, whatever, I just revoke the specific key for the device (easier than it seems, fb could provide a list of them to me and I just remove one), then get a new key for a new device. I may also want to let fb do delegated auth for me, issuing a key to my browser to be used in a different non-fb hosted application.

This is a fundamentally different approach than DSSID.  On the DSSID approach, your identity *is* your key.  On your approach (which is not without merit, but is more complicated than DSSID) your identity is something to which your key(s) is/are bound, which allows you to bind multiple keys to a single identity.  This has advantages as you point out, but the burden is now on you to specify how keys get bound to identity. That is not so easy.  DSSID doesn't have this problem because keys are not bound to identity, they *are* identity.  (The DSSID approach leads to different problems, in particular, what to do when a key is compromised.  Engineering is all about tradeoffs.)

> By generalising all of this, and the requirements, we can handle all the various mental models people have of authentication, and what they feel is good / their own central premise.
> 
> The same standard functionality could support WebID, BrowserID, DSSID and any other flow or thought people have.
> 
> I'd imagine that you won't convince Henry that a public key should be the one identifier for a person, just as he won't convince you that a URI should be the one identifier for a person.

There's no problem with having a URI as an identifier.  In fact, you could view the forwarding URL produced by secure.dswi.net as an identifying URI.  The issue is not whether or not a URI can be an identifier (it can), the issue is: what is the protocol by which a URI is to be used as an identifier?

My problem with WebID is not that it uses URIs as identifiers, but rather that it is *complicated*.  Compare this:

http://www.w3.org/2005/Incubator/webid/wiki/WebID_by_examples

to this:

http://dswi.net/dssid_client_demo.html

> Similarly neither of you will convince Harry (or members of secret societies, or people who want to securely communicate with wikileaks) that users should be identified in a linkable way across domains, where using URIs or Keys as those identifiers.

Again, nothing prevents a user from procuring as many DSSID keys as they like.

However, it is worth pointing out that an identity is *only* useful insofar as it can be linked across multiple uses.  The whole *point* of identity is to allow you to reliably ascertain that one piece of data was produced by the same entity which produced some other piece of data.  (See below.)

> 
>>> f) factor out URI/UID identification, and have them as optional extras, this would allow specific origins to provide keys for clients which are associated with specific identifiers behind the interface.
>> Again, this would undermine the central goal of DSSID, which is to keep things simple.  The baseline assumption is that a user has a single key and uses that one key for everything unless and until he has a compelling reason to do something different.
> 
> Simplicity need not come with assumptions.

Maybe not.  But making reasonable assumptions is one way to keep things simple.

>>> IMHO all of these protocols are pretty much the same at an abstract level, they're just mapped to different technology choices, and occasionally have some nice extras, and occasionally have a load of extras which aren't needed.
>> Yes, that's true, but the devil is always in the details.  And in particular, the UI matters.  A lot.  Both for users and relying parties.
> 
> So separate the UI out as being of no concern.

Huh?!?

> Thus far, I think everybody agrees that public keys are the way to go, where one agent trusts a key, the other agent holds they private part, and it's verified that the private key is currently held.

It is far from clear to me that everyone agrees on this, but I would be thrilled to learn that I was wrong about that.

> Some people have done that using nonces and via javascript (as you have), others have done that via certs with http+tls. Both of you would like a reliable identifier over time for authenticators, other people and usecases want no persistent identifiers pass over when authenticating.

I don't know what you mean by "no persistent identifiers when authenticating."  That sounds like an oxymoron to me.  Even an identity generated for the express purpose of maintaining anonymity (as in your wikileaks use case) only has value if it maintains some kind of persistence across more than one interaction with wikileaks.  I don't see how anything that could reasonably be considered an "identity" could have any value at all unless it's verifiably bound to more than one datum.

rg

Received on Monday, 8 October 2012 19:06:43 UTC