Re: ISSUE-9 [was Re: ISSUE-30: Key import/export?]

On 03/04/2013 09:23 PM, Ryan Sleevi wrote:
> On Mon, Mar 4, 2013 at 12:06 PM, Harry Halpin <hhalpin@w3.org> wrote:
>> On 03/04/2013 08:05 PM, Richard Barnes wrote:
>>> /me parachutes in mid-thread
>>>
>>> It sounds to me like you guys are talking past each other.
>>>
>>> Harry, it sounds like your concern is what happens to a key after it
>>> leaves the browser context, i.e., after it's exported.  So, say, an app
>>> generates an RSA key pair for key wrapping, then exports the signing key to
>>> a server, so that the server can read the user's messages.  Is that the sort
>>> of privacy risk you're worried about?  If so, then I don't think there's any
>>> disagreement that this is a real risk, and one that needs to be addressed.
>>
>> That is one risk. There may be more :(
>>
>> I'm also trying to figure out if pre-provisioned keys - which my mistake,
>> can include asymmetric and symmetric it appears, the latest editors draft is
>> inaccessible from the web-page  - could present a privacy issue.
>>
>>   Can we get in a situation where a key is created in a WebApp, leaves the
>> browser context, and re-appears (i.e. found using the Key Discovery
>> mechanism?). Should users then have to go through some kind of prompt or use
>> File API to select the key?
> I don't really follow what your concern is here.
>
> In the API, minus Key Discovery, is that theres no persistent storage.
> If your concern is a user creates a key, exports it to a service,
> clears local storage, and then has a web page import the key back and
> add it to localStorage - then that's absolutely no different than
> anything else with localStorage (or any other web storage mechanism).
> That's the whole point of why we're avoiding defining a new storage
> mechanism.

I agree with avoiding defining a new storage mechanism due to privacy 
concerns as well.

I'm also trying to figure out  what the Key Discovery interactions could 
be with the API, as well as any other wider interactions in the browser. 
I'd like a better idea of these before shipping the spec to PING and 
closing key-related issues.

>
> If you're specifically concerned about Pre-provisioned keys - then
> yes, they absolutely present privacy concerns. That's part of what's
> addressed in the Key Discovery draft. What I don't see is how that
> relates to ISSUE-9 or ISSUE-30 - the privacy concerns are a distinct
> issue, independent of import/export.

See below.
>
> Harry,
>
> it would help if you could try to put your specific concerns, as it
> relates to ISSUE-9, together. I sense a general unease, but without
> understanding your objections, I cannot provide an argument as to why
> this has already been addressed.

I think that if we have the movement of keys between security 
boundaries, privacy concerns may require user interaction and I feel we 
haven't discussed this issue very much.

Three examples:

  For example, a WebApp generates a key and ships it to the server which 
stores it outside the session. Seems like a user interaction there would 
be a bit much. How about if it's private key material though?

Then on the level of Key Discovery, there could be arguments both for 
and against user interaction in determining if a key should be imported 
using Key Discovery. Perhaps that could ameliorate the privacy concerns 
that resulted in Key Discovery going into a separate document and some 
implementers not wanting it.

Lastly, is there be a way for the user agent to export key material 
outside the browser and then re-import it using Key Discovery, and thus 
present the "super-key" problem mentioned earlier, including the use of 
libraries/APIs outside the Web Crypto API?


      cheers,
          harry

>
>> Do we not want users to have the ability to export keys with user control?
>>
>> These are all important questions. I agree with the editors trying to get
>> rid of them (i.e. limiting to ephemeral keys) may be the most secure and
>> privacy-respecting way to deal with them. But I am nonetheless concerned,
>> and want to discuss before closing issues and shipping to PING for a privacy
>> review.
>>
>>
>>> If you want some examples of how you import/export keys of all types, the
>>> PolyCrypt demo has several examples going to/from JWK.
>>> <http://demo.polycrypt.net/>
>>> <http://demo.polycrypt.net/x509/>
>>>
>>> The current API doesn't really do anything to address this risk, either.
>>> It seems like the right thing to do here is to somehow control export
>>> (import seems like less of a concern).  However, the assumption in the
>>> current draft seems to be that apps can freely import/export keys without
>>> any control.
>>>
>>> Does that at least accurately capture the concern?
>>
>> Thus, my concern with closing ISSUE-9 and ISSUE-40 until we have some review
>> from security/privacy experts. I know the editors have done a great job, but
>> I'm concerned the rest of the WG is not paying attention.
>>
>>
>>>
>>>
>>>
>>> On Mar 4, 2013, at 1:53 PM, Harry Halpin <hhalpin@w3.org> wrote:
>>>
>>>> On 03/04/2013 07:44 PM, Ryan Sleevi wrote:
>>>>> On Mon, Mar 4, 2013 at 10:43 AM, Harry Halpin <hhalpin@w3.org> wrote:
>>>>>> On 03/04/2013 07:22 PM, Ryan Sleevi wrote:
>>>>>>>> To re-iterate, I'm not asking about export/import in terms of the
>>>>>>>> WebIDL
>>>>>>>> as
>>>>>>>> currently written.
>>>>>>>>
>>>>>>>>     I'm asking about the notion that it is feasible developers may
>>>>>>>> want to
>>>>>>>> read/write key material outside the browser. In which case, there's a
>>>>>>>> privacy angle that needs to be addressed.
>>>>>>>>
>>>>>>>> I'm pretty sure that's where the worries underlying ISSUE-9 come
>>>>>>>> from,
>>>>>>>> and
>>>>>>>> ISSUE-30.
>>>>>>> We addressed ISSUE-9 - long ago - by saying it would not, beyond what
>>>>>>> Mark's draft says. This was the entire crux of key discovery.
>>>>>> Key Discovery only addresses symmetric pre-provisioned keys last time I
>>>>>> checked.  We have not formally closed ISSUE-9 or the import or export
>>>>>> of
>>>>>> keys outside of the browser to my extent except in that very limited
>>>>>> case.
>>>>>>
>>>>>> We can deal with ISSUE-9 and ISSUE-30 by moving them to the Web
>>>>>> Discovery
>>>>>> product. That is not closing them. That is moving the feature to a
>>>>>> different
>>>>>> product.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> If we want to say "import/export" is single-session and ephemeral,
>>>>>>>> that's
>>>>>>>> fine although that eliminates a number of use-cases. When I brought
>>>>>>>> up
>>>>>>>> the
>>>>>>>> fact that all keys are ephemeral at the last telecon, it seemed folks
>>>>>>>> in
>>>>>>>> the
>>>>>>>> WG were surprised and wanted further discussion.
>>>>>>> That's what it has said from the beginning. Key import/export has
>>>>>>> always been separate from key discovery - the latter being potential
>>>>>>> issues for ISSUE-9/30, but having absolutely nothing to do with the
>>>>>>> import / export operations as they've ever been written.
>>>>>> I'm saying "Key Discovery" is only symmetric keys.
>>>>> That is not the proposal.
>>>> Then where is the WebIDL that deals with import/export into the
>>>> non-browser filesystem?
>>>>
>>>>>> The issue is still open
>>>>>> and I don't think has been adequately discussed, but I do sympathize
>>>>>> with
>>>>>> just closing it as many in the WG are not actively paying attention.
>>>>>> People
>>>>>> need to understand that by closing these, we're limiting ourselves to
>>>>>> pre-provisioned symmetric keys and ephemeral keys.
>>>>> No, we are not.
>>>> OK, then how do you handle the import and export of key material outside
>>>> the browser in a case that isn't pre-provisioned symmetic keys.
>>>>
>>>> I don't see anything in either the API or Key Discovery draft. And *if*
>>>> there is something, my privacy concerns hold.
>>>>>> I understand many in the
>>>>>> WG are not paying that active attention, so I'm bringing this up.  When
>>>>>> most
>>>>>> people say "import/export" they imagine that it means importing and
>>>>>> exporting outside the browser as well I imagine.
>>>>>>
>>>>>>      cheers,
>>>>>>          harry
>>>>>>

Received on Monday, 4 March 2013 21:01:32 UTC