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

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.

> b) removing sessions (makes it stateless)

The DSSID protocol is stateless.  What made you think it wasn't?

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

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

See above.

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

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

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

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

rg

Received on Monday, 8 October 2012 17:23:44 UTC