RE: Use case classification, and associated security models

You make good points. Specifically, the idea that a persisted key created in-browser may need to cross origins later is a valuable one.

So if I were to reformulate the original taxonomy as:


1.       Keys whose lifetime is limited to one session (and therefore implicitly one origin)

2.       Keys which are persisted across sessions but limited to an origin (e.g. the origin that creates the key explicitly expresses a wish that no one else use this key)

3.       Keys that are persisted across sessions and can be used by multiple origins (pre-provisioned keys also fall into this class, though we do need to think about privacy issues)

Would that be a more useful classification? Should a persisted key created by an application default to #2 or #3?

From: Ryan Sleevi [mailto:sleevi@google.com]
Sent: Wednesday, June 13, 2012 6:03 PM
To: Vijay Bharadwaj
Cc: Wan-Teh Chang; public-webcrypto@w3.org
Subject: Re: Use case classification, and associated security models


On Wed, Jun 13, 2012 at 5:46 PM, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com<mailto:Vijay.Bharadwaj@microsoft.com>> wrote:
Sorry, my original statement was not worded very well.

The idea I had in mind was that the scope of the name in scenarios #1 and #2 need not (should not?) exceed the scope of the key. In #1 the key is only meant to be used by the one app, and therefore it's okay if it cannot be referred to outside that app. Therefore in general other servers cannot probe for it. In #2 there is nothing to name. The key is not persisted - the app is just creating a key object by importing a blob received through some other means, and once it's done using it the key object can go away.

In other words I'm trying to limit consideration of cross-application long-lived keys (and hence the key querying issues) to scenario #3.

Does that make more sense?

Hi Vijay,

I'm still not sure I understand the motivation for what seems like essential limitations.

For example, for scenario #1, I imagine the possibility may arise that the user wishes to re-use the key across multiple origins. It does not fit into your scenario #3 model - specifically, it is not pre-provisioned by some signing provider. It's a key that lives in the browser.

Let's use secure messaging as an example, since that touches on both scenario #1 and scenario #2, and I think may aptly illustrate my thoughts.

Scenario #1:
- Alice and Bob exchange authenticated messages via Carol's web service. Alice and Bob are not particularly concerned with privacy, but they are concerned with authenticity. Using a particularly hand-wavey mechanism, when Alice and Bob were registering with Carol's service, they created some public/private key pairs to be used to authenticate their messages. They may have generated these keys via their UA when registering with Carol's site, they may have exchanged them in-band (trust on first use) or out-of-band (key signing parties?), regardless, Alice and Bob both have public keys for eachother.
- Alice and Bob decide that Carol's service is no longer up to the task of serving their needs, so they wish to migrate to Charlie's site, which offers services similar to Carol's.
- Can Alice and Bob continue using their keys, originally created/"bound" to Carol's site, with Charlie's site?
- If not, why not?

Scenario #2:
- Alice and Bob are again exchanging secure messages via Charlie, an intermediary, this time using Off the Record messaging (ala TextSecure et-al), meaning the focus is also on encryption and key derivation.
- Alice and Bob decide to migrate from Charlie's service to Carol's.
- Can Alice and Bob continue using their derived keys?
- If not, why not? Does this mean they need to redo key exchange in order to migrate to Carol?

I don't think I see the special distinction between Scenarios #1 - #3, as you outlined them. I think the re-use of keying material will be an important part of flexibility between web sites and services. Yes, I realize it opens possible privacy concerns, but I don't believe any more than Scenario #3, and I think fundamentally it serves the users and site operators if keys are portable between origins, with the appropriate security constraints.

Further, in my above example, consider the example where Carol and Charlie are the same site operator/legal entity, and they simply are going through a rebranding effort. In the origin-bound/domain-bound security model, with no key portability, it creates an artificial cost for operators who may wish to shard domains / change domains / etc.

Cheers,
Ryan


From: Ryan Sleevi [mailto:sleevi@google.com<mailto:sleevi@google.com>]
Sent: Wednesday, June 13, 2012 10:50 AM
To: Vijay Bharadwaj
Cc: Wan-Teh Chang; public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>

Subject: Re: Use case classification, and associated security models

On Wed, Jun 13, 2012 at 7:57 AM, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com<mailto:Vijay.Bharadwaj@microsoft.com>> wrote:
One more clarification - I'm also implicitly making the assumption that keys used in scenarios #1 and #2 are not eligible for naming (at least as exposed outside the app), and cannot be queried for by a server. Names are only for long-term persisted keys with trusted provenance as in scenario #3. Specifically, keys that are provisioned out-of-band or created as part of something like a certificate enrollment operation signed by an out-of-band provisioned key.

Could you explain a bit more about this?

I would think that some form of symbolic naming will be an important part of making a usable API. I'm not sure the use case for why they wouldn't be needed?

If a web application wishes to use multiple RSA keys, which it provisioned via scenario #1 during some prior visit, what is the intended way for it to disambiguate the keys.


-----Original Message-----
From: Vijay Bharadwaj [mailto:Vijay.Bharadwaj@microsoft.com<mailto:Vijay.Bharadwaj@microsoft.com>]
Sent: Wednesday, June 13, 2012 7:23 AM
To: Wan-Teh Chang
Cc: public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
Subject: RE: Use case classification, and associated security models

The only API-level difference between #1 and #2 in my mind was that #1 talked about a GenerateKey operation (and sort of implied an ExportKey operation) whereas #2 talked about ImportKey. So from an API perspective, the difference is that #1 requires a strong source of randomness and an ability to generate keys (including things like prime number generation and so on) whereas #2 doesn't.

>From the perspective of key provenance, in #1 the key is generated within the app so the browser knows who generated the key and can tag it with appropriate metadata. In #2 the browser doesn't necessarily know where the key came from - it is embedded in some protocol that is run by the app - so the browser cannot validate provenance. However, I don't think this needs to be reflected in the API separately - the fact that an app does an ImportKey operation should indicate that the app is responsible for ensuring the provenance of the key.

-----Original Message-----
From: Wan-Teh Chang [mailto:wtc@google.com<mailto:wtc@google.com>]
Sent: Tuesday, June 12, 2012 4:54 PM
To: Vijay Bharadwaj
Cc: public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
Subject: Re: Use case classification, and associated security models

Hi Vijay,

Thank you for writing this up.

I agree that the design of the Web Cryoto API can be divided into two parts:
- key management
- the actual crypto operations that take a key object

As for the three scenarios of key management you described, the difference between scenario 1 (Ephemeral or local-only keys) and scenario 2 (Ephemeral keys obtained through key agreement) does not seem important for the API design. How do you think the API should reflect the different security models between scenario 1 and scenario 2?

To me, the important distinction is between scenarios 1 & 2 and scenario 3. In scenarios 1 & 2, the browser knows which website generates or imports/derives the key.  That knowledge is recorded persistently and can be used to determine which website is authorized to open or use a key in the future if the key is persistent.

Wan-Teh