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

"Bron Gondwana" <> Tue, 08 January 2019 02:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 86BD2130E76; Mon, 7 Jan 2019 18:52:53 -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=TAl0w3Mk; dkim=pass (2048-bit key) header.b=GuivZxBf
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 22ctcsTmRfyY; Mon, 7 Jan 2019 18:52:52 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 57D8212D4EB; Mon, 7 Jan 2019 18:52:52 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 17CC422075; Mon, 7 Jan 2019 21:52:51 -0500 (EST)
Received: from imap7 ([]) by compute6.internal (MEProxy); Mon, 07 Jan 2019 21:52:51 -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=HL4BTD2SkBjgXcL7t7ukDcUKv wF2DsDxizyTIpzuHq0=; b=TAl0w3Mk9GOTBLTs4hLxgrZc4xoRR8kHChdg80i6u JZ+pke6qzBDTbQNMLrT1wM5gDRErqgwUdb4/G8DK9nGlecwe3ZibOtAC5LJL2AE4 +5dD2+S3LGjuvYuxJa+q20a8Qb2FeSyclWwd+e2zrzdmn1XMVv2wIqeFaEgeMqAf Q5+M2kxXP9ebcvf6my6oEv4nrwJduPeBrVC8MnLRT9t8hmDRS/BuWzB/xCMTrexO J9fRnoBRPUc9Koyzt3gbIfuzDUZ3V2ZE88xO6pCQF4QmFoHYyf0Rk83MnwIsonSd iEezp08qIlgYioZuxYukdxW5ZlrtPTtR6tOtXepi9LeLw==
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=HL4BTD2SkBjgXcL7t 7ukDcUKvwF2DsDxizyTIpzuHq0=; b=GuivZxBfoDUOgdATqgbeMZ0ac12c/XW+j 60h/SqREKkQdi27aU/6QR1jEabhLHZi4c+aPOqtuT6azZf5Yv7F+ebi4Eo9eq8/o loYiOBBavo9zprjQXIyy0fsWS8U3XrqXg+x08E2sjmI8JboNjZChaSh2Xv1jHJxQ 6eVyNsSldstK6uxma2k5NnkyJj2V1QZIMM8kGrfmKYVni3OcXyBUIEv7wXxJjrp/ f/6kECkDnPkYnbYupbHHasePrjS+arThc8/1u/LBbXDYfBaFoeHcEOXBgT3xHYZp xxWexkfdGggAA3hT68vmMB7Vud+oBCBZd/w6Al6SnPmI5usZ6tU/g==
X-ME-Sender: <xms:ghA0XMj_GwD58FhkGgPq0Eup7OFjpGOdCELliRXAYMH2cW7umaAYjw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrvdekgdehgeculddtuddrgedtkedrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfuehrohhn ucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghm rdgtohhmnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:ghA0XFyhjLHbN2KoZx3EhLb5hKOTPTJLVPvtijXUVT5Bo_p3WYE3ZA> <xmx:ghA0XM-LbqixH4BO5PM24Hy84_FxVzbgHPAEfGnvzl99sP5IAltvpg> <xmx:ghA0XFIXILPWP8RVmmbGSBmChFCgJRC-6-vFHMLAj1KOu16JiEijVA> <xmx:gxA0XB4pqTQRpVjJ9XIwi08pji1i4kvWRPxFRWs-H63WqevBjrB2MA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3DDC1203BE; Mon, 7 Jan 2019 21:52:50 -0500 (EST)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.1.5-739-g7452a1e-fmstable-20190103v1
X-Me-Personality: 56629417
Message-Id: <>
In-Reply-To: <>
References: <> <> <> <> <>
Date: Mon, 07 Jan 2019 21:52:48 -0500
From: "Bron Gondwana" <>
To: "Barry Leiba" <>, "Tero Kivinen" <>
Cc: "Benjamin Kaduk" <>, "IETF JMAP Mailing List" <>, "Kurt Andersen (IETF)" <>,,,
Content-Type: multipart/alternative; boundary=f800bcbd89b2475e9e7a25f195986367
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:52:53 -0000

On Tue, Jan 8, 2019, at 00:22, Tero Kivinen wrote:
> Barry Leiba writes:
> > I agree with Ben that when documentation has been lacking in the past we may
> > need to fix that in current documents. The problem, I fear, is that we write
> > much of this, especially at the app layer, to the wrong readers, so let’s think
> > about the shared mailbox case, for example, and see if we know what will
> > actually help, rather than tick off some IETF-process-related box.
> > 
> > What we write in RFCs is primarily for software developers. It would be truly
> > bad if security/privacy warnings dissuaded developers from supporting shared
> > mailboxes: any mail system that lacks such support would be hobbled and bad.
> > 
> > So the best we could try would be to get vendors to copy or paraphrase our
> > warnings in their documents, and/or to show warnings when the features are
> > configured at installation. I think it’s unlikely to happen. Similarly, when
> > a user shares a mailbox a popup could show... also unlikely.
> > 
> > And what are we going to say? That sharing a mailbox that contains personal
> > mail can expose private information? That’s at the same time so obvious as to
> > be silly, and entirely irrelevant to the actual shared-mailbox use cases.
> > 
> > I think the best approach is to give examples of common use cases for sharing. 
> > That might be informative and might actually prompt some vendors to include
> > similar examples in their doc.
> There is already huge difference in sharing mail and sharing
> calendars. Most of the calendars support easy way of sharing only
> limited set of data, i.e., you can mark entries as private where those
> will not be shared out, or will be shared out only as "busy", i.e.,
> you can only see person is not available but not what calendar entry
> is.
> In mailboxes we do not have that kind of features. One thing we could
> suggest to implementors to allow sharing subfolders of the actual
> account instead of full mailbox, i.e., allow filtering rules to mark
> emails to specific folders, and only share those folders. I.e., create
> rules that puts all emails with specific keywords / or from specific
> users etc to subfolder and share this.
> This would allow solving some of the privacy issues when sharing
> mailboxes. The same privacy issues are mostly already solved for
> calendar, but not at all for mail...

I feel like we're talking at cross purposes here. I'm not sure which mail services you've used before, but every mail services I've used with mail sharing allows you to share individual sub-mailboxes only. I've been using JMAP in exactly that way, with individual notifications folders shared to me from other accounts, and not the full contents of those accounts.

> So if we provide such examples and features in our protocols, perhaps
> the implementors would implement them, and perhaps then we can
> actually make people to get some privacy...

Sharing individual folder is precisely what RFC3501 specifies and RFC4314 expands on, and JMAP is duplicating that same pattern. I don't like the idea of changing the examples just because one reviewer has not personally experienced a use-case for a feature. I have never heard of a case of people feeling that their privacy is negatively impacted by the fact that there are ACLs on their mailboxes. A server could easily provide backdoor access into data WITHOUT telling users via the protocol, so as Barry said - not having that ability just makes a less useful server, not an increase in privacy.



 Bron Gondwana, CEO, FastMail Pty Ltd