- From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- Date: Fri, 09 Dec 2011 16:53:38 +0000
- To: David Dahl <ddahl@mozilla.com>
- CC: Harry Halpin <hhalpin@w3.org>, public-identity@w3.org
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. > 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:-) > 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. > 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). S. > > Cheers, > > David > > ----- 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 9:00:41 AM >> Subject: Re: New "Goals" (use-cases) - Is your use-case there, accurately described? >> David, >> >> On 12/09/2011 02:49 PM, David Dahl wrote: >>> Harry: >>> >>> The "messaging" use case is a really big deal - this is the singular >>> use case that I had in mind when creating DOMCrypt. This kind of >>> functionality will make it possible for web developers to easily >>> devise all kinds of new, more secure communications tools on the >>> web. >> >> Rhetorical question really: What makes you think "developers" will >> do this better ("more secure") than the TLS folks have done it? >> >> I think an API can help with security at a different layer from >> TLS, and that's the point here and is worth doing, not that it'll >> be "more secure" in some undefined sense. >> >> In many cases the outcome will be less "secure" than using TLS >> but still ok. >> >> In some cases, the outcome will be broken and insecure applications >> because people didn't know how to design security things and that'll >> turn out to be a problem for someone. >> >> In other cases, using this API will really produce a "more >> secure" outcome compared to the status quo, but let's not pretend >> that's going to happen all or most of the time. >> >> S. >> >>> >>> Cheers, >>> >>> David >>> >>> ----- Original Message ----- >>>> From: "Harry Halpin"<hhalpin@w3.org> >>>> To: public-identity@w3.org >>>> Sent: Friday, December 9, 2011 6:54:55 AM >>>> Subject: New "Goals" (use-cases) - Is your use-case there, >>>> accurately described? >>>> I have to admit I'm disappointed that we haven't had more good >>>> use-cases >>>> come up on the mailing list, and while lots of people have >>>> discussed >>>> particular features, very few people have discussed use-cases. Note >>>> that >>>> without use-cases, we will start withdrawing features. Here's the >>>> current list [1]. >>>> >>>> I've done my best with the fairly small bits of text I've gotten to >>>> craft some use-cases. Please inspect and make sure the wording is >>>> right, >>>> and suggest to add/remove use-cases and connect the use-cases to >>>> actual >>>> features. >>>> >>>> Also note that we will send this charter to AC review now *after* >>>> Christmas break. We could have done it earlier had people been a >>>> bit >>>> more focused on the mailing list :) >>>> >>>> cheers, >>>> harry >>>> >>>> [1] http://www.w3.org/2011/11/webcryptography-charter.html#goals >>> >>> > >
Received on Friday, 9 December 2011 16:54:11 UTC