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

"Neil Jenkins" <> Tue, 08 January 2019 02:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F364C130EA8; Mon, 7 Jan 2019 18:30:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.982
X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=wt8WQvpN; dkim=pass (2048-bit key) header.b=L5rWvRS9
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uJ3VSUumH6Oy; Mon, 7 Jan 2019 18:30:11 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EDB0D130EA3; Mon, 7 Jan 2019 18:30:10 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 8A4D124537; Mon, 7 Jan 2019 21:30:09 -0500 (EST)
Received: from imap7 ([]) by compute6.internal (MEProxy); Mon, 07 Jan 2019 21:30:09 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=message-id:in-reply-to:references:date:from :to:cc:subject:content-type; s=fm1; bh=hBmqAZEWT4x1NqB554GwLTo2o c0z4YvHBuLTf3vqLyU=; b=wt8WQvpN5CNhDbKsyYLbwvFyaX1wzrl+N+4YQQfIG /dYGtj1gnd3RaraL3c5TqV+g4vLLP5LH0o2SSGs8U4iJ1520cWxrYhLqAg+zHkQK WLYDyPnibe8ZMSB2R6AH6lHhE07FlhCFkEuirhMInIUOlu9TvTDZLW3ZfduNAFXb xd+NogF7ADXavL/fVM9q/9ZUMvIc3YGqZ/RySRuXdJ1mMUuEZVVxRLLoDei3wrPS ffL6fRH1QcbQjN+G7RDit4fF8KTigH1vsSHVtx2WP5kaKPxnn6cTw39xlcpxNgaI 8WvVKxoMxi9n1wc0VIDp0UAQyhMGHNC7TNT5rTtgtUY8A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=hBmqAZEWT4x1NqB55 4GwLTo2oc0z4YvHBuLTf3vqLyU=; b=L5rWvRS9NAUFEi6qFlDpC+v48mg53NSop NW39Y+/a04emD3Au03o9V6TT0d5S5IklQ9MclnnP++Omn38Oon3Ovz+TZe4Lzj9r 8F1+qEfUspNeNJTn2OaAOOnsdJxIcWmgAXJfeGKlnL0tGxJjRbcXaNCg/kDfy59k 2w5olju3RH3XTAu2Ud+dqis5d9vHD+9hzSkPBZsaAg7rRpRdZPFvKi6De+Uloc8Z ALRLulfBMKTBv/SFMXk4WnJni267UJAhLXiDl86b5x5q+VKkfjMupIgdn8VuKQTF m8lGXEB1I+E0i9oHzp+8VXolPJpt6b6RVhZMr33OjkBFih5OcFDlw==
X-ME-Sender: <xms:MAs0XLWA7loSTbEAzaeiUZCNdm6K1SJ5OdxN-B7_cYBZnXZR2ul6Tg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrvdekgdegleculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne goufhushhpvggtthffohhmrghinhculdegledmnecujfgurhepofgfkfgjfhffhffvufgt segrtderreerreejnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehnvghilh hjsehfrghsthhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehgihhthhhusgdr ihhonecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilhhtvg grmhdrtghomhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:MAs0XOeGBxLyvdSUm2G19ZmW7Uemb7VBHnLtxzOPRfYzJxRtBDSsIg> <xmx:MAs0XBlGwvDZvjwjf8eLvVOkYfIhMhestarIH4x5h2h2GuPwds4r5Q> <xmx:MAs0XICMvSpKWFnKwLEpF1AkYKracKR1UAp7Swh86UBL0N6wX165xQ> <xmx:MQs0XC8VbTScHwq73jxspoTlBslTzP-whSbA2zhHkJt9gXagnR1w3w>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id A5D6F203BE; Mon, 7 Jan 2019 21:30:08 -0500 (EST)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1
X-Me-Personality: 64588216
Message-Id: <>
In-Reply-To: <>
References: <> <> <> <>
Date: Mon, 07 Jan 2019 21:30:07 -0500
From: "Neil Jenkins" <>
To: "Tero Kivinen" <>
Cc:, "Bron Gondwana" <>, "IETF JMAP Mailing List" <>,,
Content-Type: multipart/alternative; boundary=9ebb9715cf3f4a36b4e65b8b9eecb72d
Archived-At: <>
Subject: Re: [secdir] Secdir last call review of draft-ietf-jmap-core-12
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 Jan 2019 02:30:13 -0000

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