CloudServices/Notifications/Meetings/2011-03-03-Crypto

The goal of this meeting was to have a closer inspection of the push notification Crypto-system, as well as the security of the system as a whole.

This is a high risk project as far as security and privacy are concerned. The privacy and security goals are not clear and threats to the user's privacy/security have not been (completely) documented. The feature allows third-party service providers to present content in the browser in a way that bypasses all current security UI that we have. It is very much like a a one-way email system. Security specialists and especially people who are familiar with the security considerations of messaging systems should help create the threat model for this feature. (Example threat: we must restrict embedding of linked content in notifications for the same reason we restrict it in email in Thunderbird.) It would be a massive understatement to say that the list of problems mentioned below is incomplete.

Before the meeting, the goal was to do everything we could do to make service providers anonymous to us (Mozilla). At the end of the meeting, there seemed to be agreement that we were basically going to do the opposite of that and run the equivalent of a certificate authority (CA) so that we could authenticate service providers--not only to our own notification servers, but to third-party notification servers and to end-users. Doing this securely is a major high-risk project (in terms of security and even legal liability) in its own right. It isn't clear that we can do this cheaper/better/faster/more-securely than existing certificate authority do. Alternative designs should be seriously considered.

The crypto aspects are going to change/expand substantially after the above design work is done, especially when it comes to authenticating service providers. We cannot have the same person design the crypto related parts and then review them; we are going to need multiple highly-qualified people to design/review the crypto-related aspects.

Problems and Solutions

Problem: Can still infer where notifications are coming from using reverse DNS lookup
- Solution: Users can run their own server if this is a serious concern

Problem: (Social Attack) Consider the following -- you are logged in to Facebook on a friend's computer. You leave the computer and your friend registers for notifications on their computer with you still signed in. Result: your friend now receives all notifications intended to be sent to you.
- Solution: Recommend web apps keep track of subscriptions so users are made aware of them. Web apps can also use email confirmation if security is absolutely necessary.

Problem: Service providers (i.e. web apps) will want to be sure that decryption keys are securely stored on the client.
- Solution: Seems to be more of an OS problem. Should use a keychain to store keys if available. If someone has access to your computer you're hosed anyway.

Problem: If a service provider gets compromised (i.e. all of their tokens and public keys are exposed) then attacker can spam all tokens. This is a very bad possibility.
- Solution: Provide a mechanism to disable subscriptions. There are two possibilities here:
  - Force web apps to acquire an api key, and have Mozilla be a central authority for handing out these keys. If a developer needs to pull the plug, they can disable the key. Personal notification servers will have to poll a blacklist to see which keys are disabled.
  - Simply provide a mechanism for web apps to terminate subscriptions. This can send a notification to clients telling them to delete the subscription from their list of keys, and alerting the user to the termination.
- Note: There was a lot of debate over what should be done regarding this possible situation. Having Mozilla be a centralized authority is somewhat undesirable, but in the situation when a web app is compromised and it has had all its tokens/keys deleted by the attacker, the web app would have no way of revoking each token individually. Is this something we need to sacrifice decentralization over increased security (but as well a higher maintenance cost)? At the end of the meeting, this was still an open issue.

Try padding messages so it can't be deduced what type of notification you are receiving based on the size.

HMAC needs to verify the entire message, not just payload. Outermost JSON should have three fields: token, HMAC, and everything else.

On initial token exchange, web app should be able to specify a set of links (e.g. using a regex) that the client is allowed to follow-through via clicking (e.g. for Facebook they can route all links through "www.facebook.com/l/.*". This ensures that if someone does acquire a token that they can't send a phishing link to www.evilsite.com/phishy.

Schedule meetings with: