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

Tero Kivinen <kivinen@iki.fi> Mon, 07 January 2019 13:22 UTC

Return-Path: <kivinen@iki.fi>
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 661A6130E46; Mon, 7 Jan 2019 05:22:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.421
X-Spam-Level:
X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779] autolearn=unavailable autolearn_force=no
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 xMEPjOpsJ0vA; Mon, 7 Jan 2019 05:22:47 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0983E130DE9; Mon, 7 Jan 2019 05:22:46 -0800 (PST)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x07DMehU002280 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 7 Jan 2019 15:22:40 +0200 (EET)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x07DMeBW003930; Mon, 7 Jan 2019 15:22:40 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-ID: <23603.21152.388621.403480@fireball.acr.fi>
Date: Mon, 7 Jan 2019 15:22:40 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Barry Leiba <barryleiba@computer.org>
Cc: Benjamin Kaduk <kaduk@mit.edu>, IETF JMAP Mailing List <jmap@ietf.org>, "Kurt Andersen \(IETF\)" <kurta+ietf@drkurt.com>, draft-ietf-jmap-core.all@ietf.org, iesg@ietf.org, secdir@ietf.org
In-Reply-To: <CALaySJKezOW02CUfUnCSTUfC4CTcrmLnFu-Ttwd4U3Cn7Txt-A@mail.gmail.com>
References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <CABuGu1oM4qBcMNxh=rnWCSD-tVJYcNmDaL+orwBqq=OAvKWOZg@mail.gmail.com> <20190105185050.GB28515@kduck.kaduk.org> <CALaySJKezOW02CUfUnCSTUfC4CTcrmLnFu-Ttwd4U3Cn7Txt-A@mail.gmail.com>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 26 min
X-Total-Time: 4 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/97FtMSAZeEg-8vw0CVcVMB7bjG4>
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: Mon, 07 Jan 2019 13:22:48 -0000

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

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...
-- 
kivinen@iki.fi