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

On Mon, Mar 4, 2013 at 1:01 PM, Harry Halpin <hhalpin@w3.org> wrote:
> 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?

Keys persist beyond sessions - they're not that ephemeral, but they
are tied to local storage and users' defined session lifetimes.

Regardless though, the server is the one that generated the key in the
first place - or chose to use the web crypto API.

The question you should be asking is "Could I do this entirely in JS
today", the answer is clearly yes, therefore it's absolutely *no* new
security threat.

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

I don't see how you're conflating Key Discovery with Key Import. Key
Import just vends a Key object - the only guarantee it makes about
longevity is that the given Key object is only valid for the session,
unless it's stored into some mechanism that permits long-term storage.

So if the Key Discovery API had something like
"WriteThisIntoPermanentStorageThatIsntLocalStorage()" method, then
sure, we'd be talking about this - otherwise, I don't see what your
concern is. You're just getting an ephemeral object.

>
> 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?

Import != Key Discovery.

Export = Raw bytes - NOT some "Persist Magically" feature.

>
>
>      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:09:10 UTC