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

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

Received on Thursday, 23 May 2013 17:05:33 UTC