Re: [secdir] Secdir last call review of draft-ietf-jmap-core-12

["Neil Jenkins" <[e-mail]>]

On Tue, 8 Jan 2019, at 12:17 AM, Tero Kivinen wrote:
> Actually I think adding confirmation step will make the push
> notifications more reliable, as that will give you positive feedback
> that your push notifications do work.

The issue is that push services (e.g. Apple's APNS and Google's FCM) do not guarantee that any particular push will be received. They normally will, but may not, especially if the device goes offline for a while. So if your first push doesn't make it through your push never works. It's likely to be rare, but painful when it happens and makes it feel unreliable.

> It is really annoying trying to debug which firewall / proxy / encryption is causing the notification to be blocked, if I need to reregister again for every time and need to then somehow still cause one push notification to be sent before I can see does it work. 

I'm not sure what you're referring to here. Do you mean the JMAP (application) server connecting to the push server? Or the push server connecting to the client (which is not part of JMAP at all, but where you're more likely to run into issues with corporate firewalls and the like)?

> My understanding is that RFC8030 does not connect random urls,

My understanding is that is incorrect. There are three entities involved in an 8030 push system, and JMAP is only involved with two of them:

 * The client, which wants to receive the push notifications (the JMAP client)
 * The application server which contains the data and wants to send the push notifications (the JMAP server) 
 * The push server (3rd party, depends on the device what is possible)

The situation of the client/application server being one entity and the push server being a completely unrelated entity is what 8030 is designed for. For example, each browser implements the Push API <https://w3c.github.io/push-api/>, whereby if you have a web app you can ask the browser for a push subscription endpoint, then send it to your application server to connect to. The application server does not know in advance which browser the user has or what domains that browser currently uses for push subscriptions. It simply gets given an arbitrary URL to post to. 

JMAP is not defining anything new here. It is just defining the application server portion exactly as expected by RFC8030.

> the push notifications are received by client doing GET request to the
> subscription server and then later server using server push to that
> connection or something like that (in section 6 of the RFC8030).
> Usually that is only way things can work, as most of the people are
> behind firewalls / NATs / Proxies etc, thus connecting to them from
> outside is impossible or hard.

Yes, this is how the client receives the data from the push server in RFC8030. This is entirely orthogonal to what we are discussing though.

> The interaction between UA and the Application server is using
> "an application-specific method" …
> The verification would be inside this application-specific method,
> thus it is not covered in the 8030 because of that.

Hmm, yes I see your point, although it seems odd for it not to mention at all given this is going to apply to pretty much every app that uses this system; not specifically JMAP.

> but if server just answers HTTP ok 200 back, and JMAP server will be
> happy to keep sending notifications.

Yes, this is indeed a risk, and I agree that a confirmation step would be the only way to mitigate this.

> Attacker can also do 10000 subscriptions to same victim (perhaps using
> different URLs, but destioned to same victim). It can do this
> overnight, and then on the morning when someone triggers event the
> victim will suddenly receive 10000 event notifications
> (https-connections) from the well connected JMAP server farm, and will
> be completely swamped before it can even respond to any errors to
> those notifications.

I would expect the JMAP server to rate limit the number of push subscriptions any one user may have to something considerably lower than that. If the attacker had compromised many accounts on the JMAP server though, it could set up push subscriptions with each of them but then it would have to coordinate making a change in each of those accounts at the same time in order to flood the target server with a large single burst of requests, which is a much harder thing to do.

Summing up, I think that adding a confirmation step removes a small risk of being able to use a JMAP application server as a DDOS vector, but adds a small risk of the push not being received and the push system failing to establish. (Although, the client would at least know this was the case so could alert the user and give them the option to try again.) Would anyone else like to weigh in on the relative merits of the options here to help come to a consensus on the way forward? I would be particularly interested to hear if this was discussed at all, and any conclusions reached, in the development of RFC8030.

Neil.