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

[Ned Freed <[e-mail]>]

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

AFAICT it's different in the sense that this is the first push email
notification mechanism we have standardized. Push notifications also
aren't mentioned in RFC 5598.

So we get stuck with documenting the security concerns.

An update to RFC5598 may also be order, but that's a problem for another day.

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

I'll first note that although the JMAP specification refers to the IMAP ACL
security model extensively, RFC 4314 is not in the references list. That needs
to be fixed, and a note in the security considerations section saying that the
security considerations for IMAP ACLs apply to JMAP would also be good.

And if the security considerations in the IMAP ACL document are
deemed to be insufficient, further elaboration of some additional points may
also be in order.

As for fairness, the goal here is to produce quality standards. Sometimes
achieving that goal means you get stuck with stuff you'd rather not have
to do.

				Ned