Re: comments on web crypto API: Side effects of a low-level API [1/6]

On Thu, May 23, 2013 at 10:05 AM, Ryan Sleevi <sleevi@google.com> wrote:

> On Thu, May 23, 2013 at 1:35 AM, Nikos Mavrogiannopoulos
> <nikos.mavrogiannopoulos@esat.kuleuven.be> wrote:
> > Hello,
> >  Our comments on the available Web Cryptography API are given below and
> on
> > the few next e-mails.
> >
> > === Side effects of a low-level API ===
> > A low level API into javascript moves the notion of standards' based web
> > communications security (which is now only available via the TLS
> protocol),
> > to a web site-based communications security. Any website can advertise
> > security features such as encrypted uploading of files, but a user can
> never
> > verify whether the algorithms used are standards' based, or are correctly
> > used. Most importantly he can barely verify that the algorithms are used
> at
> > all. As it is now the API looks suitable for javascript plugins inside
> > browsers or to intranet applications, but not for the public Internet.
> >
> > A solution to that approach would be to offer high level API to handle
> the
> > common of the expected use cases of the low level API, and that high
> level
> > API will use standardized protocols, implemented in the browser. For
> > example:
> > * An API to upload an encrypted and authenticated file
> >  -> the browser uses the standardized procedure and the user is notified
> by
> > the browser that his file will be encrypted prior to uploading
> >
> >
> >
> >
>
> This API is not trying to replace TLS.
>
> The discussion of high-level versus low-level has been treated at
> great length in this working group - perhaps the single largest issue
> after pre-provisioned keys ("supercookies").


Just for the record - and, Ryan, you know this - pre-provisioned keys are
they are presently specified in the Key Discovery draft are not
"supercookies" by any common definition of that word. They are
origin-specific and subject to the same user controls as ordinary cookies.
There is one difference in that the user cannot cause them to take on a new
value, but I don't believe this merits the moniker "super".


> This WG has repeatedly
> asserted that we are NOT trying to provide a high-level API - that is,
> the goal is to provide a suitable set of cryptographic primitives that
> allow for a wide variety of protocols and applications to be
> developed.
>
> Some of these applications MAY be designed with good intention, but be
> insecure. That's life. A web author can design a page that allows for
> cross-site scripting or cross-site request forgery, or any number of
> other insecure practices. It is explicitly NOT a design goal of this
> API to try to make such things impossible, as it runs directly counter
> to the goal of providing a flexible, protocol-agnostic API that allows
> for richer web applications.
>
>