Re: New "Goals" (use-cases) - Is your use-case there, accurately described?

----- Original Message -----
> From: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
> To: "David Dahl" <ddahl@mozilla.com>
> Cc: "Harry Halpin" <hhalpin@w3.org>, public-identity@w3.org
> Sent: Friday, December 9, 2011 10:53:38 AM
> Subject: Re: New "Goals" (use-cases) - Is your use-case there, accurately described?
> Hi David,
> 
> On 12/09/2011 03:36 PM, David Dahl wrote:
> > TLS provides for transport security, this API is about fully
> > client-based crypto.
> 
> That's a false dichotomy.

Not really, this is the argument about how "we have SSL", so "there are no worries, man" - am I correct? That is how I have interpreted what you said.

> 
> > We are seeing commercially available SSL MitM devices available for
> > sale, and CAs are being broken into on a monthly (it seems) basis,
> > with revelations of certificates being issued to unknown entities
> > that allow these thieves to masquerade as Google.com and other
> > domains. Also, unless I am missing something, TLS does not allow you
> > to prevent the server/third parties from capturing plain-text
> > content.
> 
> And you expect a client-side API to fix all that? You must
> be very... optimistic:-)
> 

Now you are putting words in my mouth. I am talking about layers of security here, and increasing user control in the DOM. I am not talking about fixing the CA system.

> > Properly used -
> 
> Hmm.
> 
> > and it is being designed to make it hard to use it wrong,
> 
> I don't know how to do that. I do know ways to badly design
> crypto APIs, but I don't know how to design one to make it
> hard for a developer to screw up. I guess its a useful design
> goal for the API developers though, even if not that much
> can really be done.

Your only inputs to this API are a typed array of data to encrypt and a TypedArray representing a public key. That's pretty hard to get wrong.

> 
> > this API will has the potential to help a developer build more
> > secure messaging tools.
> 
> I'd love to see some evidence for that claim about "more secure"
> or at least some analysis to back up the argument. I've seen
> neither and I don't think its at all useful to oversell things
> like this.
> 
> > Many "secure" messaging tools are being built right now in an
> > insecure manner. Web devs are rolling their own crypto and using
> > libraries that expose key material to content JS - not to mention
> > the slow performance issues. Web devs are already way ahead of
> > browser makers here, to the detriment of endusers. We are playing
> > catch-up, and we have the ability to safely expose proven crypto to
> > the DOM.
> 
> There we do agree. And it seems to me that the corollary of
> that argument is: the fewer API calls they have to use, the
> more everyone gets to use better tested stuff (i.e. encourage
> use of TLS + key extraction to flog my own favourite dying
> horse).

How will TLS + key extraction make this API better or more usable to you? More details would help me grasp your argument. 


Regards,

David

Received on Friday, 9 December 2011 18:04:24 UTC