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

["Bron Gondwana" <[e-mail]>]

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.

Regards,

Bron.

--
 Bron Gondwana, CEO, FastMail Pty Ltd
 [e-mail]