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

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.

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

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

>> d) adding an additional, optional, nonce (protect against replays, additional protection, spot checks etc)
> 
> See above.

likewise, thus optional.

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

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

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

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

>> Would be nice to define and standardize the intersection, instead of forcing a plethora of specs on the net/web which are fundamentally the same, only differing by forcing a particular technology choice, or optional extra, as mandatory.
> 
> Absolutely agree.  Which is why I think pushing towards simplicity is potentially beneficial.

Also agree, and I'd suggest that:
1) it can be even simpler than proposed
2) there need not be any assumptions which conflict with others.

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.

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.

There's definitely an intersection, and definitely fairly well known 
optional functionality that people want too.

Best,

Nathan

Received on Monday, 8 October 2012 17:58:34 UTC