W3C home > Mailing lists > Public > public-webcrypto@w3.org > October 2012

Re: Draft blog post for WebCrypto API

From: Harry Halpin <hhalpin@w3.org>
Date: Sat, 20 Oct 2012 19:40:03 +0200
Message-ID: <5082E1F3.3000005@w3.org>
To: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
Last version, will go on Monday morning unless otherwise halted. All 
changes will be put in. Wow, sorry its taken so long but had lots of 
proposed changes from WG and W3C folks:

Here is latest version of blog post. Would like to have it out Monday 
morning. I think it addresses all your points:

Title: Re-igniting the Javscript Cryptography Flame War

Recently, the W3C has released as a First Public Working Draft the Web 
Cryptography API [1], which defines a number of cryptographic primitives 
to be deployed across browsers and native Javascript environments. As 
has been discussed in a number of blog-posts [2], cryptography in 
Javascript within web browsers is unsafe at best today. However, 
technically the Web Crypto API is a WebIDL that could be bound to 
programming languages beyond Javascript and native Javascript 
environments can solve many of these problems. Back to the Web, even 
with excellent implementations such as the Stanford Javascript Crypto 
Library [3], browsers still have to download possibly untrusted 
Javascript cryptographic code to obtain basic cryptographic 
functionality not provided natively by Javascript such as key storage.

  Yet is Javascript cryptography doomed on the Web?  Much of the 
critique of Javascript cryptography boils down to a critique of the 
security of the Web itself, and as has been shown by the W3C and browser 
vendors - the Web Platform can evolve. Due to TLS, almost every web 
browser and operating system already contains well-verified and reviewed 
cryptographic algorithms. Given that there is already cryptography in 
the browser hidden under TLS, this API simply exposes low-level 
cryptographic functionality to WebApp developers through a standardized 
interface, with the value of the API being given by enabling 
applications that require features such as cryptographically strong 
random number generation, constant-time cryptographic primitives, and a 
secure keystore. No one doubts that without these functions, Javascript 
web cryptography would be a good idea.

The Web Cryptography API provides cryptographic primitives, but the API 
itself does not provide the security to protect those primitives from 
known attacks on browsers. To mitigate against those attacks, you need 
to use other specifications and implementation-specific mitigations. For 
example, one can use CSP to prevent a certain class XSS attacks [4], and 
the Web Cryptography API does not tackle the wider issue of the 
malleability of the Javascript run-time environment. Getting these 
security considerations right to enable the trusted use of cryptography 
with Web Applications will require holistic thinking about attack 
surfaces and threat models. This API does not change the fact that the 
server controls the client in Web applications, yet there are a number 
of use-cases, ranging from checking digital signatures to out-of-band 
key provisioning to even encrypted chat, that our API hopes to enables. 
These use-cases in general require the end-to-end authentication of 
data  has been passed along several intermediaries or via an 
non-Web-based channel.

One complaint with the Web Cryptography API is that the Working Group 
decided to expose the low-level functionality first rather than aiming 
only for a high-level API aimed at the developer on the street who may 
not have a grasp of the finer details of cryptography. The Working Group 
did this on purpose after taking a survey of users [5], in order to 
allow experienced developers to build the functionality needed across 
the largest number of use-cases, but a "high-level" API that makes using 
cryptography easy for Web developers is still on our agenda [6]. 
However, the Working Group decided to iron out the low-level details, in 
particular as regards keys and key storage, before moving to thinking 
about a simple higher-level API.

A second complaint is that the current Web Cryptography API exposes 
legacy cryptographic algorithms that can be used and implemented 
insecurely, yet these are still needed in order to allow Web Application 
developers to create applications with interoperability with widely used 
applications such as GPG, SSH, and the like. In our next iteration of 
the Web Cryptography API, we will include appropriate security 
considerations so that web developers do not mistakenly use 
cryptographic algorithms with known flaws. However, as cryptography is a 
moving field, we cannot guarantee that today's robust and secure 
solution will not be tomorrow's security considerations.

  Is releasing this cryptography in Javascript to developers 
responsible?  There are lots of use-cases, and while we realize that 
some of them are controversial, the potential good of enabling richer 
web-apps that can use cryptography outweighs  some of the controversial 
points that have been raised about the availability of cryptographic 
APIs in the browser. Given the current dangerously insecure state of 
Javascript cryptography and the fact that developers are already 
re-implementing cryptographic functions in Javascript, the members of 
this Working Group thought taking action was necessary. Yet what we in 
the Working Group are really interested is what the wider community thinks.

The entire point of releasing a Working Draft is to get the wider input 
of the community before we set the API in stone by implementing it. 
Indeed, we purposefully released the API at an early stage, when many of 
the basic issues are still unresolved, in order to get community input. 
Indeed, most of the work of the Working Group has been on identifying 
the space of unresolved issues, ranging from how to determine where a 
key is stored and key naming. They are kept track of here, and a full 
fourteen of them are listed inline in the specification, with more in 
the issue-tracker. What we really want is detailed comments about the 
space of design issues, in particular those currently listed as open 
issues. So please take the time to carefully review the First Public 
Working Draft and send comments to the public-webcrypto-comments@w3.org 
mailing list, where we will respond to you!

On 10/10/2012 10:42 PM, Harry Halpin wrote:
> On 10/10/2012 10:32 PM, Anthony Nadalin wrote:
>> But that should be pointed out since this effort is not just about 
>> browsers so people are aware
>
> OK will add sentence in first paragraph!
>
>>
>> -----Original Message-----
>> From: Harry Halpin [mailto:hhalpin@w3.org]
>> Sent: Wednesday, October 10, 2012 1:29 PM
>> To: Anthony Nadalin; public-webcrypto@w3.org
>> Subject: Re: Draft blog post for WebCrypto API
>>
>>
>> On 10/10/2012 09:45 PM, Anthony Nadalin wrote:
>>> Why is this concentrated on the browser and really does not cover 
>>> the JS devices?
>> The post mentions "cryptographic primitives to be deployed across 
>> browsers and native Javascript environments" in the first line. 
>> However the post is a response to criticism of the API, which was mostly
>> *criticism* of browsers and thus the browser-centric nature of the post.
>> Native JS environments may be safe from some of these concerns, minus 
>> malleability.
>>
>>> -----Original Message-----
>>> From: Harry Halpin [mailto:hhalpin@w3.org]
>>> Sent: Wednesday, October 10, 2012 12:32 PM
>>> To: public-webcrypto@w3.org
>>> Subject: Re: Draft blog post for WebCrypto API
>>>
>>> Here's the latest version, with Ryan's edits checked in. Last call 
>>> for edits, otherwise it goes out tomorrow!
>>> ------
>>>
>>> Title: Re-igniting the Javscript Cryptography Flame War
>>>
>>> Recently, the W3C has released as a First Public Working Draft the 
>>> Web Cryptography API [1], which defines a number of cryptographic 
>>> primitives to be deployed across browsers and native Javascript 
>>> environments. As has been discussed in a number of blog-posts [2], 
>>> cryptography in Javascript on the Web is unsafe at best today, 
>>> although technically the Web Crypto API is a WebIDL that could be 
>>> bound to programming languages beyond Javascript. Even with 
>>> excellent implementations such as the Stanford Javascript Crypto 
>>> Library [3], browsers still have to download possibly untrusted 
>>> Javascript cryptographic code obtain basic cryptographic 
>>> functionality not provided natively by Javascript such as key storage.
>>>
>>> Yet is Javascript cryptography doomed on the Web? Much of the 
>>> critique of Javascript cryptography boils down to a critique of 
>>> current Web browsers, and as has been shown by the W3C and browser 
>>> vendors - the Web Platform can evolve. Due to TLS, almost every web 
>>> browser and operating system already contains well-verified and 
>>> reviewed cryptographic algorithms. At its core, the Web Cryptography 
>>> API will simply expose this functionality to WebApp developers, with 
>>> a focus on essential features such as cryptographically strong 
>>> random number generation, constant-time cryptographic primitives, 
>>> and a secure keystore. Without these functions, Javascript web 
>>> cryptography would be impossible.
>>>
>>> Yet we realize the Web Cryptography API is only a single component 
>>> in building the emerging Web Security model.  For example,  one open 
>>> issue is whether or not applications using the Web Cryptography API 
>>> also should be required to use CSP to prevent XSS attacks [4]. 
>>> Indeed, should and can browser vendors and the W3C as a whole tackle 
>>> the malleability of the browser Javascript run-time environment? 
>>> Without a doubt these security considerations of utmost importance, 
>>> and getting them right to enable cryptography on the Web will 
>>> require holistic thinking about attack surfaces and threat models. 
>>> There are a number of use-cases, such as checking digital signatures 
>>> to out-of-band key provisioning, that our API hopes to enables by 
>>> allowing key-based encryption and trust to be used in Web applications.
>>>
>>> One issue with the Web Cryptography API is that the Working Group 
>>> decided to expose the low-level functionality first rather than 
>>> aiming only for a high-level API aimed at the developer on the 
>>> street who may not have a grasp of the finer details of 
>>> cryptography. The Working Group did this on purpose after taking a 
>>> survey of users [5], in order to allow experienced developers to 
>>> build the functionality needed across the largest number of 
>>> use-cases, but a "high-level" API that makes using cryptography easy 
>>> for Web developers is still on our agenda. However, the Working 
>>> Group decided to iron out the low-level details, in particular as 
>>> regards keys and key storage, before moving to thinking about a 
>>> higher-level and more simple API.
>>>
>>> A second issue is that the current Web Cryptography API exposes 
>>> legacy cryptographic algorithms that can be used and implemented 
>>> insecurely, yet these are still needed in order to allow Web 
>>> Application developers to create applications with interoperability 
>>> with widely used applications such as GPG, SSH, and the like. In our 
>>> next iteration of the Web Cryptography API, we will include 
>>> appropriate security considerations to try and ensure that web 
>>> developers do not mistakenly use cryptographic algorithms with known 
>>> flaws. However, as cryptography is a moving field, we cannot 
>>> guarantee that today's robust and secure solution will not be 
>>> tomorrow's security considerations.
>>>
>>> Is releasing this cryptography in Javascript to developers responsible?
>>> Of course, cryptography can be used for both great good and great harm.
>>> Yet given the current dangerously insecure state of Javascript 
>>> cryptography and the fact that developers are already 
>>> re-implementing cryptographic functions in Javascript, I thought 
>>> that action should be taken. Yet who I'm really interested is not 
>>> what the W3C thinks, but what the wider community thinks.
>>>
>>> The entire point of releasing a Working Draft is to get the wider 
>>> input of the community before we set the API in stone by 
>>> implementing it.
>>> Indeed, we purposefully released the API at an early stage, when 
>>> many of the basic issues are still unresolved, in order to get 
>>> community input.
>>> Indeed, most of the work of the Working Group has been on 
>>> identifying the space of unresolved issues, ranging from how to 
>>> determine where a key is stored and key naming. Many of these open 
>>> issues are given in the fourteen open issues in the specification 
>>> itself, with more in the issue-tracker [6]. What we really want is 
>>> detailed comments about the space of design issues, in particular 
>>> those currently listed as open issues. Also additional use-cases and 
>>> development of current use-cases would be appreciated, which are 
>>> currently being stored on our wiki [7].
>>>
>>>     So please take the time to carefully review the First Public 
>>> Working Draft and send comments to the 
>>> public-webcrypto-comments@w3.org mailing list, where we will respond 
>>> to you!
>>>
>>> [1]http://www.w3.org/TR/2012/WD-WebCryptoAPI-20120913/
>>> [2]http://www.matasano.com/articles/javascript-cryptography/
>>> [3]http://crypto.stanford.edu/sjcl/
>>> [4]http://www.w3.org/TR/CSP/
>>> [5]http://www.w3.org/2012/webcrypto/wiki/SurveyAnalysis
>>> [6]http://www.w3.org/2012/webcrypto/track
>>> [7]http://www.w3.org/2012/webcrypto/wiki/Use_Cases
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
Received on Saturday, 20 October 2012 17:40:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 20 October 2012 17:40:13 GMT