- From: Harry Halpin <hhalpin@w3.org>
- Date: Mon, 01 Oct 2012 22:24:56 +0200
- To: Ryan Sleevi <sleevi@google.com>
- CC: David Dahl <ddahl@mozilla.com>, Emily Stark <estark@mit.edu>, Wan-Teh Chang <wtc@google.com>, public-webcrypto@w3.org, GALINDO Virginie <Virginie.GALINDO@gemalto.com>
- Message-ID: <5069FC18.5090201@w3.org>
On 10/01/2012 05:19 PM, Ryan Sleevi wrote: > > > On Fri, Sep 28, 2012 at 3:55 AM, Harry Halpin <hhalpin@w3.org > <mailto:hhalpin@w3.org>> wrote: > > On 09/27/2012 10:51 PM, Ryan Sleevi wrote: > > On Thu, Sep 27, 2012 at 12:24 PM, David Dahl > <ddahl@mozilla.com <mailto:ddahl@mozilla.com>> wrote: > > As far as use cases are concerned, I can think of 2 > offhand, and I think they cover many sites/developer needs: > > 1. Zero-knowledge cloud-storage of data: messages, > documents, etc. - in the event of a server compromise, the > attacker has nothing. > > In the event of server compromise, the attacker can supply new > hostile > script that instructs the UA to decrypt the > message/document/etc and > then supply that to the server. > > > Yes, but that requires the server interacting with the UA. In some > cases of compromise, such as server seizure, you won't have the > chance to supply a new hostile script. So its not a useless > use-case, in fact, its a quite important one. > > > Seizure by whom? > > I'm sorry, but I can't seem to find a threat model where that makes sense. Then, what threat model does crypto in JA make sense for at all? Obviously, when there's some lack of trust on the server *or* connection to the server that can be ameliorated by public key crypto. > > If worried about government seizure, they can just as well compel the > site to serve "hostile" script. Likewise, if non-government attackers > can compromise physical security, they can also presumably inject > hostile script. I would say seizure or penetration here is a valid use-case as usually the server itself or the server HD is just taken, and I am not aware of cases of server seizures forcing the injection of hostile scripts. Also, by virtue of storing secrets "in the cloud" using key material attached to the client, one can only access decrypt when the client is connected to the server, i.e. if keys are non-exportable and identified only by handlers. This would have use-cases I think re digital sigs for various identity/authentication systems, such as signing tokens in OAuth flows. > > In short, I disagree with the premise that it's truly zero knowledge - > it's still relying on the server to send well-behaved script, and that > basic trust premise does not cover situations where the server can be > coerced - whether through legal, 'extra-legal', or illegal means. > > The complexities involved with such a security model seem directly at > odds with the non-cryptographically-'gifted' users that such a > high-level API is meant to address, and seems just as dangerous to > security as offering 'footguns' like ECB or CBC. > > Of course, we can say the footgun problem is not ours to solve, since > security is a systematic approach and not a destination, but that then > runs counter to what's being argued as the reason for the high-level > API. Which is why I think we need concrete use cases :-) > > > > > Which is why I mentioned the desire for use cases, since > clearly some > of these require thinking carefully about the security model and > making sure that it's even possible to address the use cases. > > > I agree the use-cases are important, but the purpose of the > high-level API is to help meta-features for use-cases such as > "please encrypt this blob" easier to use for developers who may > not be aware of all the details. One way to look at this > systematically might be to go through all the use-cases and see > which subset require the kind of detail in the WebCrypto API, vs > say, a theoretical API that looks more like KeyCzar/DomCrypt. > > > Of the ones we have and discussed, all of them need the former. Now, > you can argue that if we only offered the latter, some would find ways > to adjust and accomodate that, but then we're back to the "people > needing to implement crypto" - by needing to write JOSE impls using > native code (just as they would need to write JOSE impls using the > low-level API offered today). > > So it doesn't solve the problem meaningfully. > > > cheers, > harry > > > > 2. Locally-encrypted data stored in browser storage - in > the event of a lost laptop, the user's data will be more > protected than if the web storage data was in plain text. > Another benefit is site operators will not have to store > sensitive PII on the server. > > Nearly every web developer I have chatted with about this > API has these 2 use cases in mind. > > Cheers, > > David > > > ----- Original Message ----- > From: "Ryan Sleevi" <sleevi@google.com > <mailto:sleevi@google.com>> > To: "David Dahl" <ddahl@mozilla.com > <mailto:ddahl@mozilla.com>> > Cc: "Harry Halpin" <hhalpin@w3.org > <mailto:hhalpin@w3.org>>, "Emily Stark" <estark@mit.edu > <mailto:estark@mit.edu>>, "Wan-Teh Chang" <wtc@google.com > <mailto:wtc@google.com>>, public-webcrypto@w3.org > <mailto:public-webcrypto@w3.org>, "GALINDO Virginie" > <Virginie.GALINDO@gemalto.com > <mailto:Virginie.GALINDO@gemalto.com>> > Sent: Thursday, September 27, 2012 1:06:51 PM > Subject: Re: Suggestions on high-level API - perhaps a > meeting next week? > > Do we have any use cases that intend to make use of the > high-level > API, beyond the understandably obvious overlap with the > JOSE use > cases? > > The feedback I saw largely came from the cryptographic > community, who > wish to see safer crypto encouraged. I can understand and > deeply > appreciate that motivation, and I think it's a good thing. > However, I > also want to make sure we're actually solving developers' > problems and > addressing their needs, and I think in order to do that, > we'll want to > make sure we're actually capturing use cases. > > I also mention this because, whether low-level or > high-level, the > API's utility is bounded by the security model and > expectations of > both end users and developers. Provably secure crypto is > useless if > it's going to be used to address a problem that > fundamentally cannot > be addressed in the web security model, which is why it is > all the > more important to be able to capture these use cases. > > I have great respect for those suggesting we should, either > exclusively or immediately, ship a high-level API, but I > want to make > sure we're solving problems, and not simply providing an > ideological > solution in search of a problem. > > On Thu, Sep 27, 2012 at 9:39 AM, David Dahl > <ddahl@mozilla.com <mailto:ddahl@mozilla.com>> wrote: > > +1 > > A high-level API is also perceived to be the only kind > of API that is usable by the majority of web > developers. I agree we should not put this off to long. > > Cheers, > > David > > ----- Original Message ----- > From: "Harry Halpin" <hhalpin@w3.org > <mailto:hhalpin@w3.org>> > To: "GALINDO Virginie" <Virginie.GALINDO@gemalto.com > <mailto:Virginie.GALINDO@gemalto.com>> > Cc: "Ryan Sleevi" <sleevi@google.com > <mailto:sleevi@google.com>>, "Emily Stark" > <estark@MIT.EDU <mailto:estark@MIT.EDU>>, "Wan-Teh > Chang" <wtc@google.com <mailto:wtc@google.com>>, > "David Dahl" <ddahl@mozilla.com > <mailto:ddahl@mozilla.com>>, public-webcrypto@w3.org > <mailto:public-webcrypto@w3.org> > Sent: Thursday, September 27, 2012 11:18:35 AM > Subject: Re: Suggestions on high-level API - perhaps a > meeting next week? > > On 09/27/2012 03:46 PM, GALINDO Virginie wrote: > > Harry, and all, > > Good to know that this high level API is not a > lost topic. Nevertheless, the WG participants made > a decision to treat later the high level API. As > such, I think that before re-opening this item - > which may be tricky as mentioned Ryan - we should > try to finalize what we have started, meaning a > stable low level API. Having said that, I see no > problem for having a call dedicated to discussing > qualities of the high level APIs you have > mentioned, in order to build our common > background. Lets scheduled this topic for one of > our Monday conf call after our next F2F meeting > somewhere mid-Nov. > > It seems the main feedback we have from the general > public is that a > "high-level" API is necessary. Although in our > original survey we had a > slight majority in favour of the low-level, I think it > would disappoint > the people watching this work if we did not have a > very "drafty" > high-level API included in the next Working Draft. > > To stabilize the low-level API would mean to go > through all the open > issues. I think having another two months to go > through those open > issues would be great, but we should reserve some > meetings for a > high-level API discussion. We may want to introduce > the topic sooner > rather than later. > > And yes, +1 to having the high-level API be > essentially an API for the > JOSE formats. > > cheers, > harry > > David, Emily, Ryan, Wan-Teh, > would this timing be suitable for you ? > > Regards, > Virginie > > > -----Original Message----- > From: Ryan Sleevi [mailto:sleevi@google.com > <mailto:sleevi@google.com>] > Sent: lundi 24 septembre 2012 22:51 > To: Harry Halpin > Cc: public-webcrypto@w3.org > <mailto:public-webcrypto@w3.org> > Subject: Re: Suggestions on high-level API - > perhaps a meeting next week? > > On Mon, Sep 24, 2012 at 1:44 PM, Harry Halpin > <hhalpin@w3.org <mailto:hhalpin@w3.org>> wrote: > > Looking at various discussions about the Web > Crypto API, it seems that > most of the concern is the "footgun" problem, > i.e. we are giving > developers a gun to shot themselves in the > foot. Most of the concern > seems to be over the JS environment as a > whole, but there is > considerable concern over the larger issues > related to the Web > Security Model (i.e. CSP.). I'll draft some > text on how the Web Crypto API only solves a > limited part of the problem (i.e. > primitives for re-implementing existing work, > random number > generation, key storage). However, it would > behoof us by our next WD > release to actually > *address* these concerns. The primary concern > seems to be having a > high-level APIs (which would require pushing > on the discovery algorithm). > > Thus, my suggestion is that we start at least > collecting examples of > good high-level APIs and comparing their > functions, and see if we can > get a clear consensus. These three come up off > top of my head: > > 1) DOMCrypt - This is David Dahl, who is one > of co-editors and a > member of our WG. > > 2) Stanford Crypto API - Dan Boneh, Mike > Hamburg, and Emily Stark (who > is on our WG) > > 3) KeyCzar - this is Steve Weis/Ben Laurie > from Google. Shall we ping them? > @Rsleevi and @wtc? > > We could get a call devoted to this topic, and > maybe invite some of > the folks that aren't in our WG. I'd be happy > to go for this next week > unless we want to prioritze other issues! > > cheers, > harry > > [1] > https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest > [2] http://crypto.stanford.edu/sjcl/ > [3] http://www.keyczar.org/ > > There is also NaCl (pronounced "salt") - > http://nacl.cr.yp.to/ - Which is Daniel J. > Bernstein (djb), Tanja Lange, and Peter Schwabe. > > However, the issue with SJCL, Keyczar, and NaCl is > that they define both APIs *and* message formats. > That is, a message protected under SJCL is not, > AFAICT, exchangeable with a message protected > under keyczar. > > As we discussed on our telecon today, and as > raised by Mike Jones, it seems equally appropriate > that we point to and encourage the IETF JOSE work, > which is (presently) focused solely on a message > format and not on an API. > > The issue with the "high-level API" is two-fold. > The only way to replace the footgun is to do the > crypto for them, and if you're going to do the > crypto for them, it needs to be interoperable > between user agents. I think JOSE's message format > does this much better, in terms of public > engagement and in addressing the cryptographic > concerns, that it may be suitable to instead look > at the high level API as perhaps simply an API for > JOSE. > > > >
Received on Monday, 1 October 2012 20:25:09 UTC