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

["Bron Gondwana" <[e-mail]>]

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:

https://github.com/jmapio/jmap/issues/274

We definitely need to document the security considerations for immediate third party push.

https://github.com/jmapio/jmap/issues/275

And look at making the push protocol have a confirmation step:

https://github.com/jmapio/jmap/issues/276

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

--
 Bron Gondwana, CEO, FastMail Pty Ltd
 [e-mail]