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

"Bron Gondwana" <brong@fastmailteam.com> Sat, 05 January 2019 22:26 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 9C380130DEC; Sat, 5 Jan 2019 14:26:33 -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=Ac4vhkIE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=drCyqhnm
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 sYkH6VPj7H7R; Sat, 5 Jan 2019 14:26:31 -0800 (PST)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2681B130E8A; Sat, 5 Jan 2019 14:26:31 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id B88D312C9; Sat, 5 Jan 2019 17:26:29 -0500 (EST)
Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Sat, 05 Jan 2019 17:26:30 -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=RA/AtDvOddrtwaEJnPyOwwlLq tPh2E+UNyhNmoL2zIM=; b=Ac4vhkIEAy4QOpwI3K9l4IVC6VzTyAqf8qaILCS64 dgM3Em022YZ95SNVsHgASCpil2Wbt8ayBf9c2y8EyYNGnvwHxF21Q6N30bdFTpm6 KoYP5ZcyjFypBhKuYolwoAyCekLbHq6HLpNDZo7gqIdJelYTUouNzkADSAlCFNRC kEhaOm6o4A3aBE2Ajb6Hh2PxxklILeDWGC2D/vHBg03FlpbdcGetXgzvTxfMWaEO wkP+Bdo+HRqH4uatMKTY/IYcc9KtE3LrzUakW9BoRXUATdisnpK4bBKQgvZGT7dd 7sB9XXdVAqfM9CJ94k1yhNvZmCTA2vl2SQftI3/EV//Qw==
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=RA/AtDvOddrtwaEJn PyOwwlLqtPh2E+UNyhNmoL2zIM=; b=drCyqhnmP2kHjXeozWqlLkLp6uKAajKDi uEvqM7ywNGbdGc7JevytpjGUBZd6LIgAygycbOYLQLLiFJyEnxYox10doWhk4Iz0 ZYViESAaUm9Jue+PoFMTfmeVZTms1k5gxBz+846xOfsKztaRPPZ5/BE3ddinMqZe FDhblK7VQcASkAYwuXPIpaBnd7cp2gscrX09xRSKtkFBUy/YRJk0sW8H5v2AjiOe j281un2VHamfJlpnIGUIrzcYZdXN0kVRSdaeZ+ytHpy4WuS7QXhauyXJJlDZZ6Yk W1yf2AVTi6ZJv5wvwH+A6wM9R2paZqMmVaMRACRTrXnr1Jnos+CeA==
X-ME-Sender: <xms:FC8xXNmf47BhpSfEpSxi0UhhJKiad73VV564bfpqPHiQUw7CawT-tA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrvdefgdduieegucdltddurdegtdekrddttd dmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhht necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucfrrghrrghmpehmrghilhhfrhho mhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuih iivgeptd
X-ME-Proxy: <xmx:FC8xXNH6uP3CtC9455jfQOgH8MVOENsyePdpeWP__XauwQpzX-twmg> <xmx:FC8xXOp9cXHFQ8ZD0-ZnD0srGR0-HrYcNJusudNnRnxozanrt75R7Q> <xmx:FC8xXB7iKVMP93ORp1hk5g9Ku7Ty_clVIEqSbqGWbsOOcnNJ8nYylw> <xmx:FS8xXN3BqWlv3MlQOc2F_J6cisEeJX6mzrw4rVa6J_GZ2jT_R76dGA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7BCFF203BE; Sat, 5 Jan 2019 17:26:28 -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: <cac325d4-e3fd-4dc1-8173-c52192a9ed5e@www.fastmail.com>
In-Reply-To: <154651703823.29557.748556981627156046@ietfa.amsl.com>
References: <154651703823.29557.748556981627156046@ietfa.amsl.com>
Date: Sat, 05 Jan 2019 17:26:26 -0500
From: "Bron Gondwana" <brong@fastmailteam.com>
To: secdir@ietf.org, "Tero Kivinen" <kivinen@iki.fi>
Cc: jmap@ietf.org, draft-ietf-jmap-core.all@ietf.org, ietf@ietf.org
Content-Type: multipart/alternative; boundary=8cb4414092ff4b229d537eb89e72113d
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/ukeMhIpoH4YoEBb5v-qttm7gp9A>
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 22:26:34 -0000

Hi All, sorry for the late reply - I'm on vacation with spotty internet. I am replying to the original message to retain the full CC list, but will mention things in the followup emails I have seen as well.

Regarding RFC4314 - that should definitely be referenced, but by jmap-mail, not jmap-core. I don't believe that that we should change the sharing example from mail to calendar - shared mail accounts are a common thing in the business world as well as in universities. I take exception to calling that "bad or risky behaviour", not all email is private personal email. It's not unreasonable to have another personal account shared with somebody though - the secretary use case often works like this, where the secretary has read access to the boss's Inbox. I've added the discussion to the ticket for RFC4314 anyway, and created it here:

https://github.com/jmapio/jmap/issues/274

We definitely need to document the security considerations for immediate third party push.

https://github.com/jmapio/jmap/issues/275

And look at making the push protocol have a confirmation step:

https://github.com/jmapio/jmap/issues/276

I believe that's everything from the thread - please let me know if I've missed any actions we need the authors to take.

Thanks,

Bron.


On Thu, Jan 3, 2019, at 23:04, Tero Kivinen wrote:
> Reviewer: Tero Kivinen
> Review result: Has Issues
> 
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG. These comments were written primarily for the benefit of the
> security area directors. Document editors and WG chairs should treat
> these comments just like any other last call comments.
> 
> This is quite complicated JSON based meta application protocol, which
> allows all kind of operations to be done on the server. The security
> considerations lists most of the security concerns, including the fact
> that owner of the account can use push event notifications to cause
> denial of service attacks against 3rd party.
> 
> Instead of just pointing it out, I think we should disallow that kind
> of DoS options, i.e., I think the push subscription needs to be
> extended to include initial verification step, i.e., when client
> registers a PushSubscription the server should immediately send one
> "event" notifying the creation of the push subscription and then when
> client sees that event it could verify that it can see it (this would
> also allow easy way to find out whether the given url actually works)
> and send verification token given in the first event back to server
> confirming that it can actually see the events.
> 
> This would forbid client to set up denial service attacks against 3rd
> parties, and would also verify that the event channel is actually
> working, i.e. the url is accessible by the server and that the keys
> are correct etc.
> 
> This document also has quite a lot of privacy concerns which are not
> addressed by it. For example email delivery and event notifications can
> leak lots of information even to passive attackers. I.e., if someone
> can see that wikileaks smtp server sends email to corporate smtp
> server, but the smtp traffic is encrypted so they do not know the
> recipient of the email, but then few seconds later see push event
> notification stream going to the Joe's laptop indicating something has
> happened in his mail box, they can find out the who the recipient was.
> 
> Of course sharing mailboxes between multiple users (one of the
> examples given in 1.6.2), has lots of privacy issues. Perhaps some
> text explaining these issues would be needed in the security
> considerations section. Also I think it would be better example to say
> people share calendars, not mailboxes, as sharing calendars between
> different users is much more common than sharing mails.
> 
> Group mailboxes do have their uses in cases of shared support mailbox,
> but it might be good idea to use that example instead of the current
> text in 1.6.2. I.e., user has their own primary mailbox, and then they
> also have access to shared support mailbox.
> 
> 

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