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

On May 24, 2013 6:46 AM, "Nikos Mavrogiannopoulos" <
nikos.mavrogiannopoulos@esat.kuleuven.be> wrote:
>
> On 2013-05-23 14:11, Anders Rundgren wrote:
>>>
>>> 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
>>
>> What you are indirectly saying is that there are cryptographic methods
>> that can guide an average "neticen".  Although I can't speak for the
>> WG (since I'm not a member), I don't think this is the general feeling.
>> You essentially have to trust a web-site for "Doing the right thing(tm)".
>> The specific use-case suffers from the fact that a user cannot know
>> how the encrypted document is dealt with _after_ it has been received.
>
>
> I don't quite agree. I don't trust any website to implement its own
secure communications protocol. For that I use TLS. I trust the site I
visit for a specific purpose (e.g. to sell books), not for designing secure
protocols. The current API cannot be used as is by an average web designer
since it requires him to become a secure protocol designer and handle low
level cryptographic aspects (which even cryptographers may get wrong). I'd
really suggest the WG to think about the target-audience of this framework
and offer an appropriate toolbox to them.
>
> regards,
> Nikos
>
>

Please realize that, as I said before, this has been discussed at great
length.

It is not a goal to train or educate someone unskilled in cryptography how
to write secure code. As my previous mail, which briefly summarized the
discussion you will find in the archives, there are plenty of ways for the
"average web developer" to do things insecurely, independent of
cryptography.

The target user is absolutely being kept in mind, and that user is the user
who is skilled in cryptography and wishes to implement a cryptographic
protocol securely. Whether they are writing it for their own application,
or bundling such work into a library that "average web developers" will
use, there is an expectation of familiarity with cryptography, algorithms,
and secure compositions.

I am sorry you disagree, but there has been extensive discussion on this,
polling, and solicitations of feedback from the community - both web
development and cryptographic - that support this approach.

You present an unrealistic and unattainable goal of trying to provide
assurances to "the site visitor." This goal can never be met, nor is it
realistic to expect of an API. A malicious or an ignorant site author can
easily *just not use the API*, and to the end user, they would never know.

While I appreciate the feedback and careful review, I do want to make clear
that the WG had already discussed this issue and resolved that our approach
is consistent with our target user, and thus will *not* be pursuing a high
level API as part of our deliverables.

Cheers,
Ryan