Last Call Review of draft-ietf-jmap-core-12
review-ietf-jmap-core-12-secdir-lc-kivinen-2019-01-03-00

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This is quite complicated JSON based meta application protocol, which
allows all kind of operations to be done on the server. The security
considerations lists most of the security concerns, including the fact
that owner of the account can use push event notifications to cause
denial of service attacks against 3rd party.

Instead of just pointing it out, I think we should disallow that kind
of DoS options, i.e., I think the push subscription needs to be
extended to include initial verification step, i.e., when client
registers a PushSubscription the server should immediately send one
"event" notifying the creation of the push subscription and then when
client sees that event it could verify that it can see it (this would
also allow easy way to find out whether the given url actually works)
and send verification token given in the first event back to server
confirming that it can actually see the events.

This would forbid client to set up denial service attacks against 3rd
parties, and would also verify that the event channel is actually
working, i.e. the url is accessible by the server and that the keys
are correct etc.

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. I.e., if someone
can see that wikileaks smtp server sends email to corporate smtp
server, but the smtp traffic is encrypted so they do not know the
recipient of the email, but then few seconds later see push event
notification stream going to the Joe's laptop indicating something has
happened in his mail box, they can find out the who the recipient was.

Of course sharing mailboxes between multiple users (one of the
examples given in 1.6.2), has lots of privacy issues. Perhaps some
text explaining these issues would be needed in the security
considerations section. Also I think it would be better example to say
people share calendars, not mailboxes, as sharing calendars between
different users is much more common than sharing mails.

Group mailboxes do have their uses in cases of shared support mailbox,
but it might be good idea to use that example instead of the current
text in 1.6.2. I.e., user has their own primary mailbox, and then they
also have access to shared support mailbox.