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

[Tero Kivinen <[e-mail]>]

Neil Jenkins writes:
> On Sun, 6 Jan 2019, at 9:26 AM, Bron Gondwana wrote:
> 
>     And look at making the push protocol have a confirmation step:
>     https://github.com/jmapio/jmap/issues/276
> 
> I'm not convinced this is necessary and/or helpful. In the current system, the
> first time a push is triggered the application (JMAP) server sends a request to
> the push server (the URL registered by the client); if this is not accepted
> with a reasonable HTTP response, it would automatically disable it. The danger
> is meant to be DOSing this URL (it's not really a push server); however with a
> confirmation step, you still need to do that first request so you're not
> reducing the number of HTTP requests. You are however relying on the push being
> received by the client in order for it to be able to complete registration, and
> all common push services do not guarantee delivery, so this becomes much less
> reliable. (With this in mind, the JMAP push system happily copes with dropped
> push packets while still guaranteeing full resynchronisation.)

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. 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 note this issue doesn't really seem to be specific to JMAP, and yet RFC8030
> (which is what the push system is implementing) does not require a confirmation
> step.

My understanding is that RFC8030 does not connect random urls, 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.

The interaction between UA and the Application server is using
"an application-specific method" which is not described in the
RFC8030:

   An application-specific method is used to distribute the push URI to
   the application server.  Confidentiality protection and application
   server authentication MUST be used to ensure that this URI is not
   disclosed to unauthorized recipients (Section 8.3).

The verification would be inside this application-specific method,
thus it is not covered in the 8030 because of that.

In Jmap case the URL can be anything in the network and server is
assumed to connect to that URL every time something happens. Yes, if
something goes wrong in that url then notifications are disabled, but
if server just answers HTTP ok 200 back, and JMAP server will be
happy to keep sending notifications.

With verification step the amplification factor would be around 1, as
attacker does subscription registration (small packet), JMAP server
sends first notification indication subscription is registed to given
url (small packet), and when JMAP server does not get confirmation
back from the attacker (which most likely cannot see the
notifications), then it will delete subscription.

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