Re: Exposing non-exportable key material (was Re: Scope of key discovery draft)

On Dec 11, 2012, at 11:55 AM, Ryan Sleevi wrote:

On Tue, Dec 11, 2012 at 11:43 AM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:

On Dec 10, 2012, at 5:01 PM, Ryan Sleevi wrote:

On Mon, Dec 10, 2012 at 4:37 PM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:

Sure, but my point is just that if "exportable = false" is to mean anything it has to mean that the implementor has taken *some* care to make it non-trivial to for scripts to get the key.

For example, if an implementation also provided a method like this:

ArrayBufferView Window.secretGetWebCryptoNonExportableKey( Key theKey )

then I think we would say that the "exportable=false" setting is a little meaningless on that platform.

Now, there is (hopefully) no need to provide any guidance that says implementations should not implement a method like the above one.

However, leaving gaping security holes in an IndexedDB implementation, such that retrieving keying material for non-exportable keys is trivial, is essentially the same thing as proving the above method. Some guidance on this might be in order: users of the API expect that storing keys in IndexedDB won't make access to non-exportable keying material any easier than it was before.


My motto has long been "You can't have a spec prevent stupid"

I agree in that everything you say is "common sense" and exactly how
it "should" be. But I don't know if the spec can provide any guarantee
that implementations "won't be stupid" or "won't make mistakes", and
so for a web developer/author, it's not really a guarantee.

That said, I have no objection to the politically balanced,
non-hostile textual equivalent of "Implementors: Don't be stupid. Use
common sense" :)


I'm suggesting a normative requirement, if we don't have it already, that "the UA SHALL NOT expose key material to scripts for keys where exportable = false". Do you disagree with that ? (it appears you did, earlier in the thread, but I'm not sure if you really meant to).

I disagree with this being necessary. It is a redundant tautology. "A
UA SHALL NOT expose key material to scripts when exportable = false,
because when exportable = false it means that a UA SHALL NOT expose
key material to scripts".

I agree with not restating things. I just want to ensure that this is the definition of the extractable attribute, and not something different.

Do you agree this is what the extractable attribute means ?



Given that, this conversation started with the suggestion that some guidance was needed to re-assure users that the above remains true when a Key is placed into IndexedDB. Similarly, guidance for UA implementors that their implementation of Keys-in-IndexedDB should not break the above requirement.

This may be obvious, though the existence of this thread is evidence against that ;-)

No, this conversation started through a misunderstanding of Structured
Clone algorithm and IndexedDB's requirements. Those ambiguities (which
I would suggest are not ambiguities of the spec itself) belong within
IndexedDB and structured clone.

While in general, I have no opposition to informational
(non-normative) implementation guidance, I do think there's great harm
that can be done by providing too much. I think this borderlines on
the "Don't write buggy code" implementation guidance, which everyone
assumes applies to "Someone Else" and "Not them". Guidance on this
issue is, in effect, saying, "Make sure you understand IndexedDB and
implement it correctly", to which every implementor will surely insist
they do, and then bugs will arise.

I think it also sets the stage for more confusion for the few
end-users who read the spec, because to the person who is not familiar
with IDB (eg: the average layperson), it creates confusion between the
security considerations and the text to have one saying "Don't expose
the keys" and the other saying "Look, realize that there's no inherent
security of keys here". These statements are not incompatible, but
they appear to be, and I'm just as concerned of that case.


For example, the implementor of the Key object and the internal code that makes that object storable in IndexedDB may not be aware of all the security properties of IndexedDB. This would be a flag to ensure that they talk to their IndexedDB security people to ensure that the SHALL NOT above remains just as true when the Key is in IndexedDB.

…Mark

I have never heard of any "IndexedDB security people". Who do you
imagine they are? IndexedDB has no inherent security properties
(beyond origin restriction).

I just mean people who really understand IndexedDB.


Really, we're talking about "Make sure your IndexedDB implementation
is spec-compliant", and needing that level of specificity in *this*
spec boggles my mind. It's not like we have to say "Make sure your
EventTarget implementation is spec compliant" or "Make sure your HTML
implementation is spec compliant", but they have just as much effect
on the key security as IDB.

I think you are at once reading too much into this discussion and missing something subtle.

If we agree that 'extractable = false' means that the UA MUST NOT expose the key material to scripts, then we are 99% done. What concerned me most is that you seemed to contradict that meaning earlier and indeed the specification doesn't clearly define the meaning this way.

The last 1% is related to the non-existence of "IndexedDB security people". We're talking about storing in IndexedDB information that at least related to this sensitive stuff (non-extractable keying material) that the UA SHALL NOT expose to scripts. Possibly, IndexedDB has not had to deal with information subject to this kind of requirement before. Perhaps, as a result, some security people do need to get involved to ensure the requirement is still met.

I got this comment internally too - it was not obvious to people that the non-extractable key material would still be 'safe' if the object was put into IndexedDB. We should make sure it is obvious.

…Mark