W3C home > Mailing lists > Public > public-web-security@w3.org > February 2015

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

From: Ryan Sleevi <sleevi@google.com>
Date: Mon, 2 Feb 2015 01:50:37 -0800
Message-ID: <CACvaWvb95z4-D+89JCi9f9yWBVi-2BuoFf+_O0ZLOY7WoiN-cQ@mail.gmail.com>
To: POTONNIEE Olivier <Olivier.Potonniee@gemalto.com>
Cc: Wendy Seltzer <wseltzer@w3.org>, public-webcrypto@w3.org, GALINDO Virginie <Virginie.Galindo@gemalto.com>, Lu HongQian Karen <karen.lu@gemalto.com>, Harry Halpin <hhalpin@w3.org>, "PHoyer@hidglobal.com" <PHoyer@hidglobal.com>, "public-web-security@w3.org" <public-web-security@w3.org>, Brad Hill <hillbrad@fb.com>
On Feb 2, 2015 1:24 AM, "POTONNIEE Olivier" <Olivier.Potonniee@gemalto.com>
wrote:
>
> Brad,
>
>
>
> The same-origin policy does not necessarily make sense for all resources
used on the web,

Yes. It does.

> in particular those that are not web-originated, such as the tokens we’re
talking about here. Just consider WebRTC, and the access it gives to the
(uniquely identifying) user voice: does this means that WebRTC should be
banned from the web?

Just to make sure the argument is explicit - are you making the claim that
SOP is violated when a user is explicitly required to grant an origin
access to their microphone, since a user's voice MAY be recognizable? And
that a user's voice print, as recorded by computer microphones, is uniquely
identifying?

I just want to make sure it is absolutely clear the argument being made.

> On a different aspect, is your geolocation protected by SOP?

Again, you need to elaborate on your argument, especially when making such
an exciting claim that the SOP is not needed.

This can have many interpretations as to what you're asking or the argument
you are implying, but one thing that is unquestionable is the restriction
of location information per-origin. That is, granting good.example access
to your origin does not transparently grant access to evil.example

>
> For such non web-originated resources, a specific security model applies.

And this is why it is so unacceptably security and privacy hostile to
consider exposing these. When discussing bringing new and powerful
capabilities to the web, it is essential to demonstrate how these
capabilities can fit and work in the existing web security model, rather
than necessarily argue that we ignore it.

>
> This is exactly what we want to set up with a proper access control
mechanism for the hardware tokens. Without assuming a priori that “hardware
will need to be adapted”, but not necessarily excluding it (although we’re
actually talking about software changes here…).
>

In order to be thoughtfully and seriously considered, I think it is not at
all unreasonable to suggest that proposals demonstrate how they fit in to
the existing web security model. If a solution does not, then it doesn't
really bear considering.

It is not an unwarranted assumption from ignorance that leads to the
conclusion that changes are needed, but rather a deep understanding and
familiarity with the technologies at play to know how fundamentally
incompatible the existing solutions are to user's privacy and security if
exposed via the Web.

To the extent it helps those arguing for the necessity of such technology
understand the threat models at play, assume every piece of software using
your device is either malware or infected with remote code execution, and
imagine trying to design a system that still protects and preserves the
privacy of users and the security guarantees of your system. In such a
model, it should be painfully clear that the existing, legacy systems are
full-stop unacceptable for the task at hand.

> --
>
> Olivier
>
>
>
>
>
> From: Brad Hill [mailto:hillbrad@fb.com]
> Sent: dimanche 1 février 2015 22:26
> To: PHoyer@hidglobal.com
> Cc: Harry Halpin; Lu HongQian Karen; public-web-security@w3.org;
public-webcrypto@w3.org; GALINDO Virginie; Wendy Seltzer
> Subject: Re: [W3C Web Crypto WG] Rechartering discussion - Gemalto
contribution
>
>
>
> 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.
>
>
>
> 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
>>
>>
>> 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>
>> Date: Wednesday, January 28, 2015 at 10:01 AM
>> To: 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>
>> Subject: RE: [W3C Web Crypto WG] Rechartering discussion - Gemalto
contribution
>> Resent-From: <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]
>> Sent: Wednesday, January 07, 2015 3:48 AM
>> To: public-webcrypto@w3.org
>> Cc: 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
>> Feel free to add you ideas and suggestions on the wiki and/or expose
your opinion and question on the public-webcrypto@w3.org or
public-webcrypto-comment@w3.org (for non W3C Web Crypto WG members).
>>
>> Regards,
>> Virginie
>>
>> [1] 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 09:54:17 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 February 2015 09:54:18 UTC