Hi All, sorry for the late reply - I'm on vacation with spotty internet. I am replying to the original message to retain the full CC list, but will mention things in the followup emails I have seen as well.
Regarding RFC4314 - that should definitely be referenced, but by jmap-mail, not jmap-core. I don't believe that that we should change the sharing example from mail to calendar - shared mail accounts are a common thing in the business world as well as in universities. I take exception to calling that "bad or risky behaviour", not all email is private personal email. It's not unreasonable to have another personal account shared with somebody though - the secretary use case often works like this, where the secretary has read access to the boss's Inbox. I've added the discussion to the ticket for RFC4314 anyway, and created it here:
We definitely need to document the security considerations for immediate third party push.
And look at making the push protocol have a confirmation step:
I believe that's everything from the thread - please let me know if I've missed any actions we need the authors to take.
Thanks,
Bron.
On Thu, Jan 3, 2019, at 23:04, Tero Kivinen wrote:
Reviewer: Tero KivinenReview result: Has IssuesI have reviewed this document as part of the security directorate'songoing effort to review all IETF documents being processed by theIESG. These comments were written primarily for the benefit of thesecurity area directors. Document editors and WG chairs should treatthese comments just like any other last call comments.This is quite complicated JSON based meta application protocol, whichallows all kind of operations to be done on the server. The securityconsiderations lists most of the security concerns, including the factthat owner of the account can use push event notifications to causedenial of service attacks against 3rd party.Instead of just pointing it out, I think we should disallow that kindof DoS options, i..e., I think the push subscription needs to beextended to include initial verification step, i.e., when clientregisters a PushSubscription the server should immediately send one"event" notifying the creation of the push subscription and then whenclient sees that event it could verify that it can see it (this wouldalso allow easy way to find out whether the given url actually works)and send verification token given in the first event back to serverconfirming that it can actually see the events.This would forbid client to set up denial service attacks against 3rdparties, and would also verify that the event channel is actuallyworking, i.e. the url is accessible by the server and that the keysare correct etc.This document also has quite a lot of privacy concerns which are notaddressed by it. For example email delivery and event notifications canleak lots of information even to passive attackers. I.e., if someonecan see that wikileaks smtp server sends email to corporate smtpserver, but the smtp traffic is encrypted so they do not know therecipient of the email, but then few seconds later see push eventnotification stream going to the Joe's laptop indicating something hashappened in his mail box, they can find out the who the recipient was.Of course sharing mailboxes between multiple users (one of theexamples given in 1.6.2), has lots of privacy issues. Perhaps sometext explaining these issues would be needed in the securityconsiderations section. Also I think it would be better example to saypeople share calendars, not mailboxes, as sharing calendars betweendifferent 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 currenttext in 1.6.2. I.e., user has their own primary mailbox, and then theyalso have access to shared support mailbox.
--
Bron Gondwana, CEO, FastMail Pty Ltd
brong@xxxxxxxxxxxxxxxx