[Bug 25721] extractable keys should be disabled by default

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25721

--- Comment #30 from Mark Watson <watsonm@netflix.com> ---
Ok, so I re-read the comments.

I am not at all sure that simply removing the possibility of extractable
secret/private keys would provide any of the benefits that are sought: If the
API did not support extractable secret/private keys it remains straightforward
for a web application to do something equivalent by generating the key
themselves in Javascript and then importing it. This would look identical to
the user, so any perceived security benefit for the user of disallowing
extractability would be illusory.

However, I do see in the discussion what appears to me to be a feature request:
a mode where the UA attests to the user that some keying material will be kept
secret from the site that is using it. Trust is not black-and-white and I can
imagine scenarios where the user might find it valuable to know that a site can
perform operations with a given key only when the user is actually visiting the
site and only on the users computer, and not at other times and in other
places.

At first glance, though, this feature seems rather hard to implement: just
because the UA tells me that some site has generated a non-extractable key does
not mean this is the key the site is using for whatever operations it is
performing. Even if all keys are non-extractable the site may still be using
some other key. Only if I also trust the assertions of the site about the key
it uses - or I have some further attestation from the UA about what is being
done with the key - do I gain some value from the non-extractability. And if I
trust the assertions from the site, I can trust it to set extractable=false
anyway and the UA attestation is of no value.

So, can we treat this as a feature request, to be considered for future
versions ? Some work is certainly required to describe the desired feature and
indeed some liaision with WebAppSec might be necessary.

I would say, though, that I find arguments along the lines of 'This is not how
the web works' as remarkably uncompelling. The implication is that the
commenter just doesn't understand some fundamental immutable property web and
if only they did they would see how spectacularly wrong they are. But the web
is a highly complex and evolving human creation: I doubt that anyone
'understands' it entirely and would be skeptical of anyone who claimed to. Even
if the web 'works' in a particular way now doesn't mean it always will. So,
it's reasonable to request features which don't fit in a straightforward way
into the existing models. The correct response (IMHO) is to explore the
underlying motivation for the request and the next steps that would be
necessary to further understand it.

There is clearly value in the UA making an attestation to the user about the to
security properties of a site (cf green padlock in the https case), so on the
face of it there seems to be nothing strange in considering whether there are
useful attestations the UA could make about a sites use of WebCrypto. I don't
think there is anything simple we can do right now, and simply removing
extractability would break some things for no concrete benefit. So, future work
?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Tuesday, 23 September 2014 22:40:46 UTC