RE: [W3C Web Crypto WG] Rechartering discussion - Gemalto contribution

> The devil is in the details, but let's at least agree on our goals - to not make any steps backwards on security and privacy as given by the Web Security Model, but to also to increase the capabilities of the Web Security Model to access hardware-bound cryptographic material that is under end-user control.

+1


-----Original Message-----
From: Harry Halpin [mailto:hhalpin@w3.org]
Sent: Monday, February 02, 2015 5:15 AM
To: Siva Narendra; Brad Hill
Cc: GALINDO Virginie; Lu HongQian Karen; Wendy Seltzer; public-web-security@w3.org; PHoyer@hidglobal.com; public-webcrypto@w3.org
Subject: Re: [W3C Web Crypto WG] Rechartering discussion - Gemalto contribution



On 02/01/2015 11:05 PM, Siva Narendra wrote:
> In my view when it comes to the legacy hardware it includes hardware
> that is only becoming more common and not less. Example in Apple Pay
> and perhaps even FIDO.
>
> So who is to say that we should something that only supports FIDO
> esply since even within FIDO the are several options. Given FIDO is
> new and learning from experiences let's us make sure when we build
> hardware support in a generic enough manner so that 5 years later we
> don't say that we need to find a way to support 'Max' or 'Heidi' or
> whatever the next thing we need for Web security.
>
> +1 for Philip's comment on WG would be place to resolve...
>
> Best,
> Siva
> On Feb 1, 2015 1:28 PM, "Brad Hill" <hillbrad@fb.com> wrote:
>
>>  I agree entirely with (b), but I think we need to start with the Web
>> security model as our first principle to build on, and hardware will
>> need to be adapted to and find ways to operate within that model.
>> That is what, e.g. FIDO has done.
>>
>>  This proposal is about starting with the first principle that legacy
>> hardware devices that were never designed for the web environment
>> must be supported, and finding ways to shoehorn them into browser
>> APIs, with the best excuse being that the "damage is already done" by
>> things like ActiveX.  We've spent a long time walking back the
>> mistakes of ActiveX, I'd not like to backtrack.
>>
>>  Basically I think this is a priority of constituencies issue.  It is
>> more important that we consider the priorities of the user in having
>> a web that isn't authenticating and cross-linking them in a
>> cryptographically strong manner without their consent, and that
>> whatever devices they do purchase or have provisioned to them are
>> able to be used in an open, safe and privacy-respecting manner.


Note that the Web Security Model is of course a good place to start and we'd expect any future standard to support it.

First, it's clear that simply violating SOP is not acceptable. Yet this does not mean that without proper authorization, as Ryan notes is done for access to microphones and FIDO has begun to do with many types of hardware tokens, that hardware support for "legacy hardware" is impossible that supports both privacy (in terms of unlinkability and power of choice) and security of users. Let's be clear - the issue is not the hardware itself, but *how* the hardware is accessed and what the hardware can reveal. Intermediation by the browser can ameliorate problems with "legacy" hardware, in the same way it ameliorates problems with access to microphones.

Second, the Web Security Model is evolving - CSP's doing a great job of showing how that can be done. Although SOP should be respected, right now the lack of support for client support in a particular class of high security applications that are forced to be, for example, Chrome extensions or native apps due to their necessitating that cryptographic operations be under the control of the user's client device without ability for the server to modify the code. To eventually support such kinds of applications should be a goal of the Web Security Model, and we're happy to see FIDO and this proposal make steps towards making that a reality.

The devil is in the details, but let's at least agree on our goals - to not make any steps backwards on security and privacy as given by the Web Security Model, but to also to increase the capabilities of the Web Security Model to access hardware-bound cryptographic material that is under end-user control.



>>
>>  I understand the concerns of application and service providers who
>> want to leverage their existing investment in billions of legacy
>> devices already in the hands of the user, but I just don't think
>> those concerns outweigh doing what is best for users and taking
>> security on the web forward instead of backwards.
>>
>>  In particular, I think if the best we can do for "privacy" for these
>> devices is to say that it is managed on your behalf through back-room
>> arrangements between your bank, government, handset provider and
>> network carrier, acting in their interests first and without your consent, (I.e.
>> GlobalPlatform / TEE solution in which your hardware token can only
>> talk to signed applications "approved" by someone else) that isn't
>> good enough, and goes against the entire open innovation model that's made the web a success.
>>
>>  -Brad
>>
>>   From: "PHoyer@hidglobal.com" <PHoyer@hidglobal.com>
>> Date: Friday, January 30, 2015 at 10:28 AM
>> To: Bradley Hill <hillbrad@fb.com>
>> Cc: Harry Halpin <hhalpin@w3.org>, Lu HongQian Karen
>> <karen.lu@gemalto.com>, "public-web-security@w3.org" <public-web-security@w3.org>, "
>> public-webcrypto@w3.org" <public-webcrypto@w3.org>, GALINDO Virginie
>> < Virginie.Galindo@gemalto.com>, Wendy Seltzer <wseltzer@w3.org>
>> Subject: Re: [W3C Web Crypto WG] Rechartering discussion - Gemalto
>> contribution
>>
>>   Brad,
>> one point that I made at the workshop is that currently centrally
>> issued eIDs are being used on the web and with web applications.
>>
>> So it is not that we are talking about introducing something new that
>> breaks privacy or security we are already in a world where this happens.
>>
>> The people in W3C and in the W3 are uniquely positioned as willing
>> experts in the field to find a solution that is
>>
>> a) homogenous in the approach and does not mean inexperienced web
>> developers have to wrestle with java / activX plugins potentially
>> putting other web apps accessed by the same browser at risk due to
>> security lapses in the plugins
>> b) can actually improve the situation and potentially find a way to
>> increase privacy and security of the existing solution especially as
>> we have mindshare of the browser development community
>>
>> I completely share your view that we need to tackle this issue but is
>> a WG not exactly the right place to do this?
>>
>> Philip
>>
>>
>> [image: Inactive hide details for Brad Hill ---29/01/2015
>> 22:52:23---I would like to see details of how this kind of API would
>> or could]Brad Hill ---29/01/2015 22:52:23---I would like to see
>> details of how this kind of API would or could interact with the
>> Same-Origin mod
>>
>> From: Brad Hill <hillbrad@fb.com>
>> To: Lu HongQian Karen <karen.lu@gemalto.com>, GALINDO Virginie <
>> Virginie.Galindo@gemalto.com>, "public-webcrypto@w3.org" <
>> public-webcrypto@w3.org>
>> Cc: "public-web-security@w3.org" <public-web-security@w3.org>, Wendy
>> Seltzer <wseltzer@w3.org>, Harry Halpin <hhalpin@w3.org>
>> Date: 29/01/2015 22:52
>> Subject: Re: [W3C Web Crypto WG] Rechartering discussion - Gemalto
>> contribution
>>  ------------------------------
>>
>>
>>
>> I would like to see details of how this kind of API would or could
>> interact with the Same-Origin model of web security, specifically:
>>
>>    1. Privacy and tracking.  How does the presence of specific crypto
>>    elements and discoverable keys which are not Origin-scoped not create
>>    privacy violations?
>>
>> 2. Origin security.  How are risks around identification of or
>> impersonation of the server-side of a transaction, and potential
>> abuse of a globally-scope key mitigated by  this kind of API design?
>>
>> Without a clear discussion of how this API fits into the existing Web
>> security and threat model, I think it is inappropriate to proceed.
>> We can't just throw away the fundamental security model that billions
>> of users and deployed applications depend on, and I see no evidence
>> (at least in these few slides) that such issues have been considered by this proposal.
>>
>> Brad Hill
>>
>> *From: *Lu HongQian Karen <*karen.lu@gemalto.com*
>> <karen.lu@gemalto.com>>
>> * Date: *Wednesday, January 28, 2015 at 10:01 AM
>> * To: *GALINDO Virginie <*Virginie.Galindo@gemalto.com*
>> <Virginie.Galindo@gemalto.com>>, "*public-webcrypto@w3.org*
>> <public-webcrypto@w3.org>" <*public-webcrypto@w3.org*
>> <public-webcrypto@w3.org>>
>> * Cc: *"*public-web-security@w3.org* <public-web-security@w3.org>" <
>> *public-web-security@w3.org* <public-web-security@w3.org>>, Wendy
>> Seltzer
>> <*wseltzer@w3.org* <wseltzer@w3.org>>, Harry Halpin <*hhalpin@w3.org*
>> <hhalpin@w3.org>>
>> * Subject: *RE: [W3C Web Crypto WG] Rechartering discussion - Gemalto
>> contribution
>> * Resent-From: *<*public-web-security@w3.org*
>> <public-web-security@w3.org>
>>>
>> * Resent-Date: *Wednesday, January 28, 2015 at 10:04 AM
>>
>>    Please review Gemalto’s contribution. We welcome your comments.
>>
>>    Regards,
>>    Karen
>>
>>    *From:* GALINDO Virginie [*mailto:Virginie.Galindo@gemalto.com*
>>    <Virginie.Galindo@gemalto.com>]
>> * Sent:* Wednesday, January 07, 2015 3:48 AM
>> * To:* *public-webcrypto@w3.org* <public-webcrypto@w3.org>
>> * Cc:* *public-web-security@w3.org* <public-web-security@w3.org>; Wendy
>>    Seltzer; Harry Halpin
>> * Subject:* [W3C Web Crypto WG] Rechartering discussion
>>
>>    Dear all,
>>
>>    Web Crypto WG charter [1] will end by the end of March. We need to
>>    prepare the next charter of Web Crypto.
>>
>>    As a reminder, the conversation has started on this page :
>>    *https://www.w3.org/Security/wiki/IG/webcryptonext_draft_charter*

>>    <https://www.w3.org/Security/wiki/IG/webcryptonext_draft_charter>
>>    Feel free to add you ideas and suggestions on the wiki and/or expose
>>    your opinion and question on the *public-webcrypto@w3.org*
>>    <public-webcrypto@w3.org> or *public-webcrypto-comment@w3.org*
>>    <public-webcrypto-comment@w3.org> (for non W3C Web Crypto WG members).
>>
>>    Regards,
>>    Virginie
>>
>>    [1] *http://www.w3.org/2011/11/webcryptography-charter.html*

>>    <http://www.w3.org/2011/11/webcryptography-charter.html>
>>
>>    ------------------------------
>>
>>
>> *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.*
>>
>>    ------------------------------
>>
>>
>> *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.*
>>     ------------------------------
>>    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
>>
>>
>>
>> ------------------------------------------------------------
>> HID Global GmbH
>> registered office: 65396 Walluf, Germany municipal court: Wiesbaden,
>> Germany commercial register number: HRB 20928 Management board: Denis
>> Hebert, Juergen Schnoebel, Marc Bielmann
>>
>> Confidentiality Note:
>> This message is intended for use only by the individual or entity to
>> which it is addressed and may contain information that is privileged,
>> confidential, and exempt from disclosure under applicable law. If the
>> reader of this message is not the intended recipient or the employee
>> or agent responsible for delivering the message to the intended
>> recipient, you are hereby notified that any dissemination,
>> distribution or copying of this communication is strictly prohibited.
>> If you have received this communication in error, please contact the
>> sender immediately and destroy the material in its entirety, whether electronic or hard copy. Thank you.
>>
>>
>
________________________________
 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.

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

Received on Monday, 2 February 2015 20:12:37 UTC