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

"Neil Jenkins" <neilj@fastmailteam.com> Sat, 05 January 2019 23:06 UTC

Return-Path: <neilj@fastmailteam.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81698130DEC; Sat, 5 Jan 2019 15:06:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.983
X-Spam-Level:
X-Spam-Status: No, score=-1.983 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] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=mDdSEfhh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IHD3uDuQ
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GB-62YSS4cUz; Sat, 5 Jan 2019 15:06:13 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1509B129AB8; Sat, 5 Jan 2019 15:06:12 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id B8A0B21B74; Sat, 5 Jan 2019 18:06:10 -0500 (EST)
Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Sat, 05 Jan 2019 18:06:10 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:cc:subject:content-type; s=fm1; bh=u10ZO7RBHZdaC77a8j3ab0x+y QvjokmxPWqgeB1HlGU=; b=mDdSEfhhj5EYH9tvHZfcF+Uy0Vb70ANrur0CAcmbE gL8GAoW1gIjekEU5U82H8ybmAQDLGKfQWaNBKMroePBtIoVykVDpNkLJ5e1h+MKM DG2AZzkyPzxNn+Bj1BDOHI42ISuiV4Jdy2bQc7TG1S2uryVsLY90ssDpx42QteQA gF7ahWTSb47dYUhzJNs+dUGbR6Hwk71fPO4Mxenx2lTk6X/BjKhLyfcNY4nuetp7 8nxVt7BQpsxvxvt3byujcw3Sy0cZU5MQ7IspzB45LS0ShYE4U9OBU7fdx3prGbRj WdNn4pKRXgXAVJGqKsyNzCQsg+soD0O2L9WaDCPi9b84A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; 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=u10ZO7RBHZdaC77a8 j3ab0x+yQvjokmxPWqgeB1HlGU=; b=IHD3uDuQpBQPEEN14s0/gxdGenvCCAGK2 aviekS2mWXTei8jp8072GHrcw+kH9hwYfgqER9MfltfNwEffiQMGWYq/V/ouVYYe 1clgCMnsikYJ1ASAzBPoIX6GwbKVPHmOvanPDJL3cxi2x4OJh4FtMNXD38zvYq2G dJPd1tcxbPsigXnLzXl0Jmfz04AJTZH3WSRKkG4j+cYExPDFxFxJ5/OuxU18oOXr 7JoQ7/vLXEOv9Lox6QN+TXRpGAHKKvB6+5ddmufET6LjeGkT3McMtTDWZZheVfgY 9clqUcJGfI4RfKCl84Tp+VlwANxKcFvXEeHOAQwDqmzhFdek9KJJA==
X-ME-Sender: <xms:YTgxXFg_3l5o-jrqU21sGZRKc-MDG6G_pNFrsYhx00KydRV9jcF0Sw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrvdeggddtjeculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuffhomhgrihhnpehhthhtphhrvghquhgvshhtshdrhihouhdpghhithhhuhgsrdgtohhm necurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilhhtvggrmh drtghomhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:YTgxXOonsZlOcxiah1BTSMHMqDIrYcwy3wjW8ni_RY-qmGaz2SbrLA> <xmx:YTgxXHyjdZaAc2Vuz19CD9ILLmDyLZjeYm8OmtqTkAFNwAQLQjkvBw> <xmx:YTgxXJmq9ZEOvb0UwnKFJGD1UJRvG4ApIv9kyFUqdOnqYe3kYRuIHQ> <xmx:YjgxXOYTbj2Qso9VvCSCdif3YC6OqqaBK-S3VYAzxDGp_GlvdC_Qjw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id A8B5D203BE; Sat, 5 Jan 2019 18:06:09 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1
X-Me-Personality: 64588216
Message-Id: <7beebd38-7999-4a49-b892-c3c75b36eab4@beta.fastmail.com>
In-Reply-To: <cac325d4-e3fd-4dc1-8173-c52192a9ed5e@www.fastmail.com>
References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <cac325d4-e3fd-4dc1-8173-c52192a9ed5e@www.fastmail.com>
Date: Sat, 05 Jan 2019 18:06:09 -0500
From: "Neil Jenkins" <neilj@fastmailteam.com>
To: secdir@ietf.org, "Tero Kivinen" <kivinen@iki.fi>, "Bron Gondwana" <brong@fastmailteam.com>
Cc: "IETF JMAP Mailing List" <jmap@ietf.org>, draft-ietf-jmap-core.all@ietf.org, ietf@ietf.org
Content-Type: multipart/alternative; boundary=579f7d2c679049869e501976f579f99c
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/0oDYb-jh_-0ZSO_9uCQ9KGazveY>
Subject: Re: [secdir] Secdir last call review of draft-ietf-jmap-core-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Jan 2019 23:06:15 -0000

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

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.

Neil.