Re: FYI: ACTION-119: Review PING comments on Web Crypto/Discovery (Web Cryptography Working Group)

All,

It looks like the PING comments below were provisional - there is a
deadline for comments on those of 10/4 - should we expect a "formal" set of
comments from them soon ?

I presume we should develop a response from the group somehow.

My comments are below...

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

MW> Seems reasonable to me.

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

Yes, this issue should be covered in the Privacy section of the Key
Discovery API. The issue is mitigated by the fact that only origin-specific
pre-provisioned keys are supported and they can only be accessed by the
origin to which they are specific. A page can "prank dial" for keys that
are specific to the origin of the prank dialler, but cannot discover
anything about keys for other origins.

>
>
> (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.

The basis is that the UA can perform cryptographic operations using the key
- operations that could not be performed if the UA did not have access to
that key. We could note that the security of the proof depends on the
secure operations that the web service asks the UA to perform and the
design of the protocol to communication between scripts and web service.

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

Yes. The named origin-specific pre-provisioned keys mechanism does not in
itself require anything more than the main document in this respect. It is
expected, though, that web services may have a priori knowledge of the key
provisioning process used and thus of the nature of the element into which
the key is provisioned (for example, was the key provisioned in to a
user-accessible plain text file on the device or into a Trusted Platform
Module). The web service can then make their own judgements about what it
means for a UA to have access to a given key. We could add some informative
text to this effect.

...Mark


>
>


On Wed, Oct 16, 2013 at 2:54 AM, GALINDO Virginie <
Virginie.GALINDO@gemalto.com> wrote:

> Hi all,
> I created an action to make sure we review the PING comments on our
> deliverables.
> Regards,
> Virginie
>
>
> -----Original Message-----
> From: Web Cryptography Working Group Issue Tracker [mailto:
> sysbot+tracker@w3.org]
> Sent: mercredi 16 octobre 2013 11:52
> To: GALINDO Virginie
> Subject: ACTION-119: Review PING comments on Web Crypto/Discovery (Web
> Cryptography Working Group)
>
> ACTION-119: Review PING comments on Web Crypto/Discovery (Web Cryptography
> Working Group)
>
> http://www.w3.org/2012/webcrypto/track/actions/119
>
> On: Virginie GALINDO
> Due: 2013-10-23
> Product: Web Cryptography API
>
> If you do not want to be notified on new action items for this group,
> please update your settings at:
> http://www.w3.org/2012/webcrypto/track/users/50298#settings
>
>
> This message and any attachments are intended solely for the addressees
> and may contain confidential information. Any unauthorized use or
> disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for
> the message if altered, changed or falsified. If you are not the intended
> recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission
> free from viruses, the sender will not be liable for damages caused by a
> transmitted virus
>