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

"Bron Gondwana" <brong@fastmailteam.com> Sun, 06 January 2019 10:57 UTC

Return-Path: <brong@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 E485E130E3F; Sun, 6 Jan 2019 02:57:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.982
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=VQ1Q7woz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sbeBd6uZ
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 IXbS6QQBsqb1; Sun, 6 Jan 2019 02:57:48 -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 C3C4E130DE9; Sun, 6 Jan 2019 02:57:47 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id CFFEB219EB; Sun, 6 Jan 2019 05:57:46 -0500 (EST)
Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Sun, 06 Jan 2019 05:57:46 -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=V9Bz/qfjju61fPu2n254j5uAu ftijAlE1hA8rSWR1qw=; b=VQ1Q7wozh1lYxD+J8KZDfRmu0kPhs55IuX8AI7F3Q hGJ9O4NT0gyBjAkOlC2DAVQjCZIyGAo4dklQsW54sl2gmZtd7Z1h/VJO/03TJp/l g3JYNVmXuqUqNBFVR0fT+IXrB0DLaT2zO8uNHB4HqAc8+B7L1u0OpQzTQIqrZ+gM Cac2qQYArwEQzezCNYMDgItDJtbPMiBYRUodVMszEJlWcU7DiHSixZYysIoXu4nU T+x2rxg3iVobUbjhjE/pKUx3vdfAHp1LpnBAjL/BGNhVkLeBBTret1C5wt4GFGf2 KaF2b0sBw59T+rmKr+sPsZ99EYPzEsBomhTEwCrljXDAg==
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=V9Bz/qfjju61fPu2n 254j5uAuftijAlE1hA8rSWR1qw=; b=sbeBd6uZVF3DgoYmdJ2iWQGSovin/axdo xijKMyD8g/cv4TA2HVpeYKTingN69P20FHxkzONdEgASeKROVyAAh6JtqUqEvBdu vRG0G6aB/7tuaA77/C8cki1xOWvveDh5vam7mFZGm46NZsNcNRh/lL6vEZ3SiqKM 0oQDKOUeOpk55cVsi2XdkUk/QYKeQJHZUtlbkdQoDDA3/Ka9JKZFt1aWzQSriQEg 2FOULZDbDFUJErZfF9mclbiOB9fDYqeRlEFbs0WMWRkSpVkGRvcRUfqqibnysKMz HSJPI7qY9jm0VLR07atXItrv+yNABhb/d089a6A5c+qG27zrszWng==
X-ME-Sender: <xms:Kt8xXC4YcLSKokE8lgMJOei-3-jpFhEE0oBINFCAGVrHmf5B2pDs8Q>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrvdehgddvfeculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfuehrohhn ucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucffohhmrghinhephhhtthhprhgvqhhuvghsthhsrdihohhupdhgihhthhhusgdrtgho mhenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrg hmrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:Kt8xXFO6ZeJwPhq9IUvvJ26zQi6IwbplThmM98EPcyFDgoBsfhk_3w> <xmx:Kt8xXN2mgIlXMBU-tVh8FWADz2y_Y_gEk0pbEJtbk9TS51ZrZ4rCJw> <xmx:Kt8xXGu6NTfE8-sTRCOornzlOdLDYwt366xcy9tU7ruScC-clwLpIQ> <xmx:Kt8xXLuD_B0lUndRwNqg0y9lY-ORWZ_AiRPqnCM0AE-KU8buDGQuVg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 28A38203BE; Sun, 6 Jan 2019 05:57:46 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1
X-Me-Personality: 56629417
Message-Id: <5c5a39bb-96e9-4a2f-bf20-4fdb1bbb6f6d@www.fastmail.com>
In-Reply-To: <7beebd38-7999-4a49-b892-c3c75b36eab4@beta.fastmail.com>
References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <cac325d4-e3fd-4dc1-8173-c52192a9ed5e@www.fastmail.com> <7beebd38-7999-4a49-b892-c3c75b36eab4@beta.fastmail.com>
Date: Sun, 06 Jan 2019 05:57:43 -0500
From: "Bron Gondwana" <brong@fastmailteam.com>
To: secdir@ietf.org, "Tero Kivinen" <kivinen@iki.fi>, "Neil Jenkins" <neilj@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=8c1e39e2af2d404592cdcc3be2a22ea6
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/lrV8wfn8-IblmcMrJchkfpA-8aQ>
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: Sun, 06 Jan 2019 10:57:50 -0000

On Sun, Jan 6, 2019, at 10:06, Neil Jenkins wrote:
> 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.

Tero - are you satisfied with this response? The fact that RFC8030 didn't see the need to add a confirmation step suggests that not having a confirmation step in JMAP isn't wildly different from current practice or current IETF standards, and Neil's justification that it makes setup less reliable for common push services seems reasonable.

If we need to beef up the language that the server MUST disable the push channel if the endpoint URL doesn't reply correctly, and maybe even a suggestion that the server rate limit individual authenticated users and similarly detect weird behaviour and limit it. It would be great to solve this with clear advice to server implementations on how to not become a DOS amplifier rather than hobble the protocol.

Cheers,

Bron.

--
 Bron Gondwana, CEO, FastMail Pty Ltd
 brong@fastmailteam.com