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

[Tero Kivinen <[e-mail]>]

Neil Jenkins writes:
> 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.

When you are subscribing the push notifications your devices should be
running and not offline. Note, that you do not need reconfirmation if
you extended the time, but only when new URL is given. If client gives
url, it should make sure it can actually receive those notifications
in the given url for few seconds... 

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

Perhaps my understanding of the jmap push service is then wrong, or
perhaps it is badly defined in JMAP. 

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

But client and application server protocol is not defined in RFC8030.
It is left outside the scope of that document. RFC8030 seems to only
document interaction between the client and push service, and
interaction between application and push service.

The URL returned from the push service is somehow magically given to
the application server and whatever verification happens there is not
covered. 

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

Looking at the text in jmap. It says in section 7.2:

   A push subscription is a message delivery context established between
   the client and a push service.

Push service is not defined in this document, and it does not refer to
RFC8030 for that term. My understanding was that push worked as
follows:

Client does PushSubscription as defined in 7.2 to JMAP server:

   Clients may create a push subscription on the JMAP server, which will
   then make a POST request to the associated push endpoint whenever an
   event occurs.

This push subscription includes an url and when something happens the
JMAP server will connect to that url and send some random garbage
(from the receiver point of view if it does not assume receiveing push
notications) to it using POST. If the receiver end is proper push
service then it will notify the client using some other means.

I.e., when email etc is received the JMAP server will then push
StateChange object (section 7.1):

   When something changes on the server, the server pushes a
   *StateChange* object to the client.

Actually that says "to the client" not to the "push service". Which
one should it be? I always assumed this StateChange object is sent to
the url given in the PushSubscription.

Hmm... and 7.2 then also uses term "push endpoint" which is not
defined anywhere? Is that the same as push service at given url or
something else:

   Clients may create a push subscription on the JMAP server, which will
   then make a POST request to the associated push endpoint whenever an
   event occurs.

Then section 7.2 seems to also describe things not related to the
PushSubscription but instead to the notifications sent by the JMAP
server. Perhaps it would be better to move that to the StateChange
object section, i.e., put all things related to the "push service" in
same place. Now it is split in two places, i.e., StateChange is
defined in section 7.1, but how to transmit that inside https POST
with content type of application/json is described in 7.2.

Also it is not clear which server this is talking about:

							The server
   is expected to understand and handle HTTP status responses in a
   reasonable manner.

Is it push service server, JMAP server, Application server (same as
JMAP server in this case?). My guess it is supposed to be JMAP server
which is actually acting as http-client and making https request to
push service, and if push service returns http errors JMAP server
acting as http-client will process those in reasonable manner. Is that
understaning correct? Perhaps rewording it a bit to make it clear.

Then I have no idea what this text is trying to say:

   The use of this push endpoint conforms with the use of a push
   endpoint by an Application Server as defined in [RFC8030].

what push endpoint? JMAP server? URL given by the client to JMAP
server? 

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

Most likely it is not describied in the RFC8030 because the details
depends on the application server. 

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

I would expect it to be very easy to find urls in host that will
return success to http posts with application/json and ignore
contents.

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

There is text saying frequency of pushes to be rate limited, but there
is no limit for number of subscriptions account can have, or even
suggestion that there should be limit.

This kind of attacks can also use multiple accounts especially if
there is some kind of public services available. 

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

As people pointed out we have imap server providing access to ietf
mailing lists. There is lots of people on those lists, and even if we
require datatracker account to be able to make subscriptions, making
those accounts require just email address and ability to receive
emails. Most likely datatracker allows creating accounts for:

[e-mail]
[e-mail]
[e-mail]
...
[e-mail]

and then making subscription for all of those accounts to all ietf
mailing lists and sending notifications to same url x...

Verification step would disable that attack vector too. 

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

Actually I think it will make push system much more reliable, as it
immediately verifies that the system is working, and you will not have
silent failure, where you just notice few days later that I have not
received any notifications, something must be broken.

> (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.
-- 
[e-mail]