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

On Tue, Dec 11, 2012 at 11:43 AM, Mark Watson <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> 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".

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

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.

Received on Tuesday, 11 December 2012 19:56:01 UTC