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

[Barry Leiba <[e-mail]>]

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.

Barry

On Sun, Jan 6, 2019 at 2:51 AM Benjamin Kaduk <[e-mail]> wrote:

> [I wrote this before I noticed that half the thread was stuck in my spam
> quarantine.  Some of the points were made already, but I've left my text
> unchanged to avoid making it even less comprehensible that it was to start
> with.]
>
> On Thu, Jan 03, 2019 at 09:21:12AM -0800, Kurt Andersen (IETF) wrote:
> > On Thu, Jan 3, 2019 at 4:04 AM Tero Kivinen <[e-mail]> wrote:
> >
> > > Reviewer: Tero Kivinen
> > > Review result: Has Issues
> > >
> > > 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.
> > >
> >
> > How is this any different than the risks present in current mechanisms
> > (websockets, HTTP, MAPI, IMAP, etc.)? I don't see this as a new risk
> being
> > introduced by the JMAP protocol.
>
> But where is it documented for those other protocols?
>
> > Of course sharing mailboxes between multiple users (one of the
> > > examples given in 1.6.2), has lots of privacy issues.
> > >
> >
> > Again, this is not a new risk being introduced by JMAP. It seems unfair
> to
> > saddle the JMAP protocol with the responsibility of documenting a
> > comprehensive set of privacy and security risks for bad or risky
> behaviours
> > that have been a wide part of common practice for decades.
>
> In general, we need to either document ourselves or point to existing
> documentation of the security considerations relating to protocols we
> publish.  "Everybody already does [bad practice X]" does not excuse us from
> ensuring that the risks are adequately documented.  Is it unfair?  Perhaps.
> But the IETF consensus so far seems to be that we need to properly document
> that which we cannot make secure, and if we're the first one to actually
> document it properly, then we do incur the extra burden of doing things
> right.
>
> -Benjamin
>