Fwd: Web Crypto - draft privacy review

Dear all.

A gentle reminder to send in your input by tomorrow.

Christine and Tara

Begin forwarded message:

> Resent-From: <public-privacy@w3.org>
> From: Christine Runnegar <runnegar@isoc.org>
> Subject: Web Crypto - draft privacy review
> Date: September 28, 2013 12:23:04 AM GMT+02:00
> To: "public-privacy (W3C mailing list)" <public-privacy@w3.org>
> 
> Dear all,
> 
> My colleague, Robin, very kindly volunteered to lead PING's privacy review of the draft Web Cryptography API [1] and the draft WebCrypto Key Discovery [2] specifications.
> 
> [1] https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html
> [2] http://www.w3.org/TR/webcrypto-key-discovery/
> 
> Many many thanks Robin!
> 
> Robin's write up of the review is set out below. 
> 
> At this time, Tara and I would like to invite comments on the enclosed review. In particular, are there any other concerns that should be included, additional suggested text for the privacy considerations sections or proposed solutions?
> 
> Please provide your comments by Friday 4 October 2013.
> 
> Regards,
> Christine
> 
> -------
> 
> W3C Web Crypto specs
> 
> Summary:
> 
> I have no changes/recommendations to suggest regarding the vast majority of the contents of these two documents, which seem to me to be apposite and sensible.
> 
> The web crypto API and the key discovery function are, inevitably, closely related, and many of the things that need to be said in specifying one apply to the other (though not all). There is therefore a judgement call about how many points deserve (or need) to be made in both documents, how many are unique to either, and how many should be made simply by reference to the other specification. By and large, I think the two documents currently get this balance about right - though in the comments below, I make a couple of suggestions for either duplicating text, or cross-referring between the two documents. 
> 
> 1 - Web Crypto API
> 
> I think it is sensible to open the Key Discovery Privacy section by noting that the equivalent section in the Web Crypto API WD applies. However, it seems to me that the "fingerprinting" concern currently expressed only in the Web Crypto spec applies also to the Key Discovery spec., and should probably be mentioned in both WDs.
> 
> However, this and the recommendations below concerning Section 5.2 Para.3 are minor nits about the organisation of content across the two documents, not about their content. 
> 
> 2 - Key discovery
> 
> Pre-provisioned keys are keys that have been placed on a device by a third party, in such a way that they can subsequently be accessed and used in support of crypto functions that third party wishes to exercise on the device (for instance, by a User Agent). They can be made specific to a named origin… that is, the key is labelled as having originated from a particular entity, and can thus be discovered and retrieved using that name. 
> 
> Because the keys are retrieved at the request of the third party (or its local UA) when the third party wishes, there's a potential privacy concern. The keys are also an identifiable object in persistent local storage - and therefore can function in ways analogous to a cookie. (On a somewhat related topic - I have similar concerns regarding the use of the "built-in object token" mechanism, especially when the object token identifier contains long apparently-random strings that are presumably unique to that user/browser/platform/interaction).
> 
> Questions/concerns
> 
> (a) The privacy section already incorporated in the Working Draft (Section 5) does a good job of describing the possible privacy implications, and suggests various mitigations. 
> 
> There is a further privacy factor, which is described in the Web Crypto WD (Section 6, para.1, "Fingerprinting") but not in the Key Discovery WD: namely that if a key discovery API is present in a given UA, a third party may derive data about the presence and possibly nature of the UA (or device) by "prank dialling" the API. That is, the attacker does not intend to discover a key, but sends a key discovery request anyway, in the hope of, essentially, finding out that there is something identifiable at the other end. 
> 
> 
> (b) Section 1 describes named-origin-specific pre-provisioned keys as allowing "a web service to establish secure proof that a UA has access to a particular key". The Scope section's comments notwithstanding, it might be helpful to indicate (either in this WD or by reference to another) what the basis of that security is. 
> 
> If the mechanism's security relies on the presence of specific UA functions (key-ring management), a local Trusted Platform Module or other mechanism, any such dependency should be indicated. For example, the WD should probably make an explicit reference to the Web Crypto WD, Section 5.2, para. 3 - which says: 
> 
> "While the API in this specification provides a means to protect keys from future access by web applications, it makes no statements as to how the actual keying material will be stored by an implementation. As such, although a key may be inaccessible to web content, it should not be presumed that it is inaccessible to end-users. For example, a conforming user agent may choose to implement key storage by storing key material in plain text on device storage. Although the user agent prevents access to the raw keying material to web applications, any user with access to device storage may be able to recover the key."
> 
>

Received on Thursday, 3 October 2013 08:10:52 UTC