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

Mark,

While I appreciate your sensitivity to the matter, I think you may be
overreacting. I did not say "pre-provisioned, origin-specific keys",
as in the Key Discovery Draft, but was referring to the general set of
pre-provisioned keys, particularly int he context of Nikos' other
comments related to Smart Card support and key generation, which is
absolutely relevant to the conversation at hand and firmly merits the
moniker "super".

Cheers,
Ryan



On Thu, May 23, 2013 at 10:51 AM, Mark Watson <watsonm@netflix.com> wrote:
>
>
> 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.
>>
>

Received on Thursday, 23 May 2013 17:54:58 UTC