Reviewer: Tero Kivinen Review result: Has Issues 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.
