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

From: Tero Kivinen <[email-masked]>
Date: Thu, 03 Jan 2019 04:03:58 -0800

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.

---

From: "Kurt Andersen (IETF)" <[email-masked]>
Date: Thu, 3 Jan 2019 09:21:12 -0800

On Thu, Jan 3, 2019 at 4:04 AM Tero Kivinen <[email-masked]> wrote:

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

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

--Kurt Andersen

---

From: Barry Leiba <[email-masked]>
Date: Fri, 4 Jan 2019 08:31:31 +0800

I think that advice to use TLS whenever possible is the extent of what
makes sense to say here.

As to shared folders, that is neither “bad” nor “risky”: it’s necessary for
many use cases.  For example, IETF itself uses shared IMAP folders to serve
up our mailing lists.  Help desks will use a shared inbox for, say,
[email-masked], to allow multiple agents to handle questions and
complaints, while maintaining accountability (each agent has a separate
login, so their activity is tracked).

Barry

---

From: Ned Freed <[email-masked]>
Date: Fri, 04 Jan 2019 13:45:49 -0800 (PST)

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

> 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

---

From: Tero Kivinen <[email-masked]>
Date: Sat, 5 Jan 2019 01:00:02 +0200

> introduced by the JMAP protocol.

There is some similarities and differences. For example http does not
have built in event notification system. In most of the other
protocols the event system notification system is built on top of the
other protocol running over for example http.

Here if I understood correctly the event notifications are generated
automatically and application writer using generic JMAP server backend
might not even have any control how those events are generated and
when they are generated. Because of this I think this issue belongs to
the JMAP protocol document.

The main difference with event notification system is, that it is not
between the two peers running the JMAP protocol, or two parties
running some external API connected to JMAP. It involves the third
party, i.e., the party where the notifications are sent to. 

Also the examples given in the document talk about mail, calendar,
contacts etc, which all are data related to privacy and where there
are lots of privacy issues, so clearly this JMAP is designed to be
used in environments where privacy concerns are important, but still
it is silent about them. 

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

If you provide example of bad and risky behaviours in your document,
you need to also include the warnings about it. Thats why I did
suggested you using different example (i.e., shared work calendar,
shared between co-workers, or shared calendar between family members).

And if you write protocol that can be used to do all kind of things
you should really write comprehensive set of privacy and security
risks inherintly associated with the JMAP protocol, and also include
some generic warnings about common mistakes that users of JMAP can do. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Sat, 5 Jan 2019 01:09:57 +0200

Barry Leiba writes:
> I think that advice to use TLS whenever possible is the extent of
> what makes sense to say here.

Using TLS does not help here, as this attack is traffic analysis
attack, and you can do traffic analysis even when all the traffic is
encrypted. The current draft already says that all request MUST use
TLS.

> many use cases.  For example, IETF itself uses shared IMAP folders to serve up
> our mailing lists.  Help desks will use a shared inbox for, say, 
> complaints, while maintaining accountability (each agent has a separate login,
> so their activity is tracked).

Agreed. I was not saying it is bad or risky, but the none of the
examples you gave are not really examples of

  ... if another user is sharing their mail with the logged in
   user, ...

All of those are examples of user gaining access of group account
(which is also mentioned). So my comment was that two individual users
sharing their individual mails with each other is not really that
common, and has much more privacy concerns than it help desk having
shared inbox. Sharing calendar entries also has privacy concerns, but
most people do understand them better and calendars provide ways of
separating private / public entries already.

So, I think changing the text:

   A single set of credentials may provide access to multiple accounts,
   for example if another user is sharing their mail with the logged in
   user, or if there is a group account.

to something like this:

   A single set of credentials may provide access to multiple
   accounts, for example if another user is sharing their work
   calendar information with the logged in user. Another example of
   cases where access to multiple accounts can be useful is when
   logged in user can also access shared group account mailbox (for
   example it help desk inbox).

would make the text better. 
-- 
[email-masked]

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 4 Jan 2019 23:10:10 +0000

From: secdir <[email-masked]> on behalf of Ned Freed <[email-masked]>
Sent: Friday, January 4, 2019 4:45 PM
To: Kurt Andersen (IETF)
Cc: IETF JMAP Mailing List; [email-masked]; [email-masked]
Subject: Re: [secdir] [Jmap] Secdir last call review of draft-ietf-jmap-core-12

It may be the first such mechanism we've standardized, but it's certainly not the first time we've contemplated push notification of email delivery. Consider RFC5435 (the Sieve notify extension), published just about 10 years ago this month. Among other things, it contains extensive discussion of security considerations surrounding push notification.

True, but shared mailboxes are hardly new. They've been around pretty much since the beginning of time. Giving advice to operators about security and privacy issues surrounding shared mailboxes or any of a number of common user practices seems, to me, to be far out of scope for an access protocol specification.

That's not to say that JMAP doesn't need to document security issues; of course it does. If those are substantially similar to, say, IMAP, then the documentation is going to be, too. And if there are issues that were missed in the past or have only recently become topics of discussion, that doesn't mean they can just be ignored. But I do think it's important to keep the scope manageable.

-- Jeff

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 5 Jan 2019 12:50:50 -0600

[I wrote this before I noticed that half the thread was stuck in my spam
quarantine.  Some of the points were made already, but I've left my text
unchanged to avoid making it even less comprehensible that it was to start
with.]

> introduced by the JMAP protocol.

But where is it documented for those other protocols?

> that have been a wide part of common practice for decades.

In general, we need to either document ourselves or point to existing
documentation of the security considerations relating to protocols we
publish.  "Everybody already does [bad practice X]" does not excuse us from
ensuring that the risks are adequately documented.  Is it unfair?  Perhaps.
But the IETF consensus so far seems to be that we need to properly document
that which we cannot make secure, and if we're the first one to actually
document it properly, then we do incur the extra burden of doing things
right.

-Benjamin

---

From: Ned Freed <[email-masked]>
Date: Sat, 05 Jan 2019 11:15:43 -0800 (PST)

> It may be the first such mechanism we've standardized, but it's certainly not
> the first time we've contemplated push notification of email delivery. Consider
> RFC5435 (the Sieve notify extension), published just about 10 years ago this
> month. Among other things, it contains extensive discussion of security
> considerations surrounding push notification.

Not really. The security considerations, while extensive, do not cover
traffic analysis of notifications pushed directly to the client, which is
the main concern here. And neither do the other RFCs defining specific sieve
notification mechanisms.

This is likely because all of the mechanisms we were standardizing have a
different set of security issues. Indeed, almost all of the considerations
covered in RFC 5435 et al. are orthogonal to the current case, which is why I
didn't suggest citing RFC 5435 et al. in the current document.

				Ned

---

From: "Bron Gondwana" <[email-masked]>
Date: Sat, 05 Jan 2019 17:26:26 -0500

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.

--
 Bron Gondwana, CEO, FastMail Pty Ltd
 [email-masked]

---

From: "Neil Jenkins" <[email-masked]>
Date: Sat, 05 Jan 2019 18:06:09 -0500

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

I'm not convinced this is necessary and/or helpful. In the current system, the first time a push is triggered the application (JMAP) server sends a request to the push server (the URL registered by the client); if this is not accepted with a reasonable HTTP response, it would automatically disable it. The danger is meant to be DOSing this URL (it's not really a push server); however with a confirmation step, you still need to do that first request so you're not reducing the number of HTTP requests. You are however relying on the push being received by the client in order for it to be able to complete registration, and all common push services do not guarantee delivery, so this becomes much less reliable. (With this in mind, the JMAP push system happily copes with dropped push packets while still guaranteeing full resynchronisation.)

I note this issue doesn't really seem to be specific to JMAP, and yet RFC8030 (which is what the push system is implementing) does not require a confirmation step.

Neil.

---

From: Barry Leiba <[email-masked]>
Date: Sun, 6 Jan 2019 09:01:02 +0800

I agree with Ben that when documentation has been lacking in the past we
may need to fix that in current documents.  The problem, I fear, is that we
write much of this, especially at the app layer, to the wrong readers, so
let’s think about the shared mailbox case, for example, and see if we know
what will actually help, rather than tick off some IETF-process-related box.

What we write in RFCs is primarily for software developers.  It would be
truly bad if security/privacy warnings dissuaded developers from supporting
shared mailboxes: any mail system that lacks such support would be hobbled
and bad.

So the best we could try would be to get vendors to copy or paraphrase our
warnings in their documents, and/or to show warnings when the features are
configured at installation.  I think it’s unlikely to happen.  Similarly,
when a user shares a mailbox a popup could show... also unlikely.

And what are we going to say?  That sharing a mailbox that contains
personal mail can expose private information?  That’s at the same time so
obvious as to be silly, and entirely irrelevant to the actual
shared-mailbox use cases.

I think the best approach is to give examples of common use cases for
sharing.  That might be informative and might actually prompt some vendors
to include similar examples in their doc.

Barry

---

From: "Bron Gondwana" <[email-masked]>
Date: Sun, 06 Jan 2019 05:57:43 -0500

> I note this issue doesn't really seem to be specific to JMAP, and yet RFC8030 (which is what the push system is implementing) does not require a confirmation step.

Tero - are you satisfied with this response? The fact that RFC8030 didn't see the need to add a confirmation step suggests that not having a confirmation step in JMAP isn't wildly different from current practice or current IETF standards, and Neil's justification that it makes setup less reliable for common push services seems reasonable.

If we need to beef up the language that the server MUST disable the push channel if the endpoint URL doesn't reply correctly, and maybe even a suggestion that the server rate limit individual authenticated users and similarly detect weird behaviour and limit it. It would be great to solve this with clear advice to server implementations on how to not become a DOS amplifier rather than hobble the protocol.

Cheers,

Bron.

---

From: Tony Finch <[email-masked]>
Date: Mon, 7 Jan 2019 12:24:52 +0000

Ned Freed <[email-masked]> wrote:
> notification mechanism we have standardized.

What about RFC 2177 IMAP IDLE?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Southeast Iceland: Northwesterly 7 to severe gale 9, decreasing 5 or 6,
becoming variable 4 later. Rough or very rough, becoming moderate later in
west. Showers at first. Poor, becoming good.

---

From: "Bron Gondwana" <[email-masked]>
Date: Mon, 07 Jan 2019 08:10:47 -0500

> What about RFC 2177 IMAP IDLE?

To be fair - IMAP IDLE doesn't involve a third party passing a notification like JMAP push can (if it's configured using a third party channel, as we do via both Google and Apple in our implementation - when talking to clients on their platforms)

Bron.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 7 Jan 2019 15:17:50 +0200

Neil Jenkins writes:
> I'm not convinced this is necessary and/or helpful. In the current system, the
> first time a push is triggered the application (JMAP) server sends a request to
> the push server (the URL registered by the client); if this is not accepted
> with a reasonable HTTP response, it would automatically disable it. The danger
> is meant to be DOSing this URL (it's not really a push server); however with a
> confirmation step, you still need to do that first request so you're not
> reducing the number of HTTP requests. You are however relying on the push being
> received by the client in order for it to be able to complete registration, and
> all common push services do not guarantee delivery, so this becomes much less
> reliable. (With this in mind, the JMAP push system happily copes with dropped
> push packets while still guaranteeing full resynchronisation.)

Actually I think adding confirmation step will make the push
notifications more reliable, as that will give you positive feedback
that your push notifications do work. It is really annoying trying to
debug which firewall / proxy / encryption is causing the notification
to be blocked, if I need to reregister again for every time and need
to then somehow still cause one push notification to be sent before I
can see does it work. 

> I note this issue doesn't really seem to be specific to JMAP, and yet RFC8030
> (which is what the push system is implementing) does not require a confirmation
> step.

My understanding is that RFC8030 does not connect random urls, the
push notifications are received by client doing GET request to the
subscription server and then later server using server push to that
connection or something like that (in section 6 of the RFC8030).
Usually that is only way things can work, as most of the people are
behind firewalls / NATs / Proxies etc, thus connecting to them from
outside is impossible or hard.

The interaction between UA and the Application server is using
"an application-specific method" which is not described in the
RFC8030:

   An application-specific method is used to distribute the push URI to
   the application server.  Confidentiality protection and application
   server authentication MUST be used to ensure that this URI is not
   disclosed to unauthorized recipients (Section 8.3).

The verification would be inside this application-specific method,
thus it is not covered in the 8030 because of that.

In Jmap case the URL can be anything in the network and server is
assumed to connect to that URL every time something happens. Yes, if
something goes wrong in that url then notifications are disabled, but
if server just answers HTTP ok 200 back, and JMAP server will be
happy to keep sending notifications.

With verification step the amplification factor would be around 1, as
attacker does subscription registration (small packet), JMAP server
sends first notification indication subscription is registed to given
url (small packet), and when JMAP server does not get confirmation
back from the attacker (which most likely cannot see the
notifications), then it will delete subscription.

Attacker can also do 10000 subscriptions to same victim (perhaps using
different URLs, but destioned to same victim). It can do this
overnight, and then on the morning when someone triggers event the
victim will suddenly receive 10000 event notifications
(https-connections) from the well connected JMAP server farm, and will
be completely swamped before it can even respond to any errors to
those notifications.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 7 Jan 2019 15:22:40 +0200

Barry Leiba writes:
> I agree with Ben that when documentation has been lacking in the past we may
> need to fix that in current documents.  The problem, I fear, is that we write
> much of this, especially at the app layer, to the wrong readers, so let’s think
> about the shared mailbox case, for example, and see if we know what will
> actually help, rather than tick off some IETF-process-related box.
> 
> What we write in RFCs is primarily for software developers.  It would be truly
> bad if security/privacy warnings dissuaded developers from supporting shared
> mailboxes: any mail system that lacks such support would be hobbled and bad.
> 
> configured at installation.  I think it’s unlikely to happen.  Similarly, when
> a user shares a mailbox a popup could show... also unlikely.
> 
> And what are we going to say?  That sharing a mailbox that contains personal
> mail can expose private information?  That’s at the same time so obvious as to
> be silly, and entirely irrelevant to the actual shared-mailbox use cases.
> 
> I think the best approach is to give examples of common use cases for sharing. 
> That might be informative and might actually prompt some vendors to include
> similar examples in their doc.

There is already huge difference in sharing mail and sharing
calendars. Most of the calendars support easy way of sharing only
limited set of data, i.e., you can mark entries as private where those
will not be shared out, or will be shared out only as "busy", i.e.,
you can only see person is not available but not what calendar entry
is.

In mailboxes we do not have that kind of features. One thing we could
suggest to implementors to allow sharing subfolders of the actual
account instead of full mailbox, i.e., allow filtering rules to mark
emails to specific folders, and only share those folders. I.e., create
rules that puts all emails with specific keywords / or from specific
users etc to subfolder and share this.

This would allow solving some of the privacy issues when sharing
mailboxes. The same privacy issues are mostly already solved for
calendar, but not at all for mail...

So if we provide such examples and features in our protocols, perhaps
the implementors would implement them, and perhaps then we can
actually make people to get some privacy...
-- 
[email-masked]

---

From: Tony Finch <[email-masked]>
Date: Mon, 7 Jan 2019 14:12:45 +0000

Bron Gondwana <[email-masked]> wrote:
> To be fair - IMAP IDLE doesn't involve a third party passing a
> notification like JMAP push can

Ah, yes, that is an important difference :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Southeast Fitzroy: Northeasterly 5 to 7. Moderate or rough. Fair. Good.

---

From: Ned Freed <[email-masked]>
Date: Mon, 07 Jan 2019 08:43:59 -0800 (PST)

> What about RFC 2177 IMAP IDLE?

IDLE is an odd mix of pull and push. I don't think it really meets the criteria
for a pure push mechanism, although on futher consideration I suppose with some
persistance and careful observation of multiple IMAP streams you could perform
this sort of traffic analysis on it.

That said, the fact that the security considerations section in RFC 2177
says in its entirety:

  There are no known security issues with this extension.

is pretty disturbing regardless. At a minimum an IDLE stream leaks information
about a particular mailbox's activity, even when uncorrelated with incoming
messages.

				Ned

---

From: Barry Leiba <[email-masked]>
Date: Tue, 8 Jan 2019 07:46:36 +0800

Hm.  I don’t see that.  All you get in response to the IDLE command is the
same stuff you get from the NOOP command or from any other IMAP command:
untagged FETCH and EXPUNGE responses.  Technically, they’re not actually
responses to the command: they’re unsolicited messages in the IMAP protocol.

What security considerations should there be for IDLE that are beyond those
for NOOP (that is, IMAP itself?

Barry

---

From: "Neil Jenkins" <[email-masked]>
Date: Mon, 07 Jan 2019 21:30:07 -0500

On Tue, 8 Jan 2019, at 12:17 AM, Tero Kivinen wrote:
> that your push notifications do work.

The issue is that push services (e.g. Apple's APNS and Google's FCM) do not guarantee that any particular push will be received. They normally will, but may not, especially if the device goes offline for a while. So if your first push doesn't make it through your push never works. It's likely to be rare, but painful when it happens and makes it feel unreliable.

> It is really annoying trying to debug which firewall / proxy / encryption is causing the notification to be blocked, if I need to reregister again for every time and need to then somehow still cause one push notification to be sent before I can see does it work. 

I'm not sure what you're referring to here. Do you mean the JMAP (application) server connecting to the push server? Or the push server connecting to the client (which is not part of JMAP at all, but where you're more likely to run into issues with corporate firewalls and the like)?

> My understanding is that RFC8030 does not connect random urls,

My understanding is that is incorrect. There are three entities involved in an 8030 push system, and JMAP is only involved with two of them:

 * The client, which wants to receive the push notifications (the JMAP client)
 * The application server which contains the data and wants to send the push notifications (the JMAP server) 
 * The push server (3rd party, depends on the device what is possible)

The situation of the client/application server being one entity and the push server being a completely unrelated entity is what 8030 is designed for. For example, each browser implements the Push API <https://w3c.github.io/push-api/>, whereby if you have a web app you can ask the browser for a push subscription endpoint, then send it to your application server to connect to. The application server does not know in advance which browser the user has or what domains that browser currently uses for push subscriptions. It simply gets given an arbitrary URL to post to. 

JMAP is not defining anything new here. It is just defining the application server portion exactly as expected by RFC8030.

> the push notifications are received by client doing GET request to the

Yes, this is how the client receives the data from the push server in RFC8030. This is entirely orthogonal to what we are discussing though.

> "an application-specific method" …

Hmm, yes I see your point, although it seems odd for it not to mention at all given this is going to apply to pretty much every app that uses this system; not specifically JMAP.

> but if server just answers HTTP ok 200 back, and JMAP server will be

Yes, this is indeed a risk, and I agree that a confirmation step would be the only way to mitigate this.

> be completely swamped before it can even respond to any errors to

I would expect the JMAP server to rate limit the number of push subscriptions any one user may have to something considerably lower than that. If the attacker had compromised many accounts on the JMAP server though, it could set up push subscriptions with each of them but then it would have to coordinate making a change in each of those accounts at the same time in order to flood the target server with a large single burst of requests, which is a much harder thing to do.

Summing up, I think that adding a confirmation step removes a small risk of being able to use a JMAP application server as a DDOS vector, but adds a small risk of the push not being received and the push system failing to establish. (Although, the client would at least know this was the case so could alert the user and give them the option to try again.) Would anyone else like to weigh in on the relative merits of the options here to help come to a consensus on the way forward? I would be particularly interested to hear if this was discussed at all, and any conclusions reached, in the development of RFC8030.

Neil.

---

From: "Bron Gondwana" <[email-masked]>
Date: Mon, 07 Jan 2019 21:52:48 -0500

> calendar, but not at all for mail...

I feel like we're talking at cross purposes here. I'm not sure which mail services you've used before, but every mail services I've used with mail sharing allows you to share individual sub-mailboxes only. I've been using JMAP in exactly that way, with individual notifications folders shared to me from other accounts, and not the full contents of those accounts.

> actually make people to get some privacy...

Sharing individual folder is precisely what RFC3501 specifies and RFC4314 expands on, and JMAP is duplicating that same pattern. I don't like the idea of changing the examples just because one reviewer has not personally experienced a use-case for a feature. I have never heard of a case of people feeling that their privacy is negatively impacted by the fact that there are ACLs on their mailboxes. A server could easily provide backdoor access into data WITHOUT telling users via the protocol, so as Barry said - not having that ability just makes a less useful server, not an increase in privacy.

Regards,

Bron.

---

From: "Neil Jenkins" <[email-masked]>
Date: Mon, 07 Jan 2019 21:54:32 -0500

On Tue, 8 Jan 2019, at 12:22 AM, Tero Kivinen wrote:
> account instead of full mailbox,

Err, not sure what you're talking about here. Most email systems already support sharing on a per-folder (or *mailbox* as they're called in IMAP and JMAP) granularity. That's why JMAP and IMAP can return you a "myRights" object with your permissions for each mailbox. Calendars are identical; you generally share on a per-calendar basis (which acts the same as a mailbox for mail; a collection of individual data items).

Neil.

---

From: "Neil Jenkins" <[email-masked]>
Date: Mon, 07 Jan 2019 22:42:31 -0500

On Sat, 5 Jan 2019, at 9:10 AM, Ned Freed wrote:
> to be fixed,

Agreed, I have now added a reference to this.

>  and a note in the security considerations section saying that the

I've read through the security considerations section here and I don't actually think any of them apply to JMAP; bear in mind the current spec does not have any way to set ACLs, it just exposes the user's current rights. (Setting ACLs is left to a future extension.)

---

I have added the following section to the JMAP Core security considerations:

*8.8 Push traffic analysis*

While the data is encrypted, a passive observer with the ability to monitor network traffic may be able to glean information from the timing of push notifications. For example, suppose an email or calendar invitation is sent from User A (hosted on Server X) to User B (hosted on Server Y). If Server X hosts data for many users, a passive observer can see that the two servers connected but does not know who the data was for. However, if a push notification is immediately sent to User B and the attacker can observe this as well, they may reasonably conclude that someone on Server X is connecting to User B.

This can be partially mitigated by the JMAP server applying some random jitter before sending out push notifications, however the jitter would have to be small so as not to affect quality of service. This is also mitigated inately on large services with high traffic flows hosting data for many users, as it becomes much harder for an attacker to correlate incoming data events with outgoing push notifications, allowing users to “hide in the crowd”.

---

I await the conclusion on whether we should add a confirmation step to push notifications, but other than that I don't believe there are any outstanding issues to address from this review. Please let me know if I've missed something.

Neil.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 08 Jan 2019 16:08:20 +1100

On Tue, Jan 8, 2019, at 14:42, Neil Jenkins wrote:
> While the data is encrypted, a passive observer with the ability to 
> monitor network traffic may be able to glean information from the timing 
> of push notifications. For example, suppose an email or calendar 
> invitation is sent from User A (hosted on Server X) to User B (hosted on 
> Server Y).. If Server X hosts data for many users, a passive observer 

Extra period here.

> can see that the two servers connected but does not know who the data 
> was for. However, if a push notification is immediately sent to User B 
> and the attacker can observe this as well, they may reasonably conclude 
> that someone on Server X is connecting to User B.

This is all good.
 
> This can be partially mitigated by the JMAP server applying some random 
> jitter before sending out push notifications, however the jitter would 
> have to be small so as not to affect quality of service. This is also 
> mitigated inately on large services with high traffic flows hosting data 
> for many users, as it becomes much harder for an attacker to correlate 
> incoming data events with outgoing push notifications, allowing users to 
> “hide in the crowd”.

This is a little problematic.  If you look at how push notification services typically manage this sort of thing, the direct mapping is often masked by a little store-and-forward, which looks like the "jitter" you suggest, but it's not really a well-proven defense against traffic analysis.

Rather than describe - in some detail  - a defense that is questionable, I would simply limit this to the facts.  Acknowledge that traffic analysis is feasible and then move on.  If you must, note the typical defenses against traffic analysis are inducing delays, padding, and mix networks.  Your suggestion here leans on delays and a single-layer mixnet at the push service.  As you allude to, these defenses each come with costs that need some consideration of the trade-offs.

Separately, you probably need to concern yourself with the push service as an attacker as well.  There's more text on that in RFC 8030 if you care to cite that.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 8 Jan 2019 16:28:05 +0200

Neil Jenkins writes:
> The issue is that push services (e.g. Apple's APNS and Google's FCM) do not
> guarantee that any particular push will be received. They normally will, but
> may not, especially if the device goes offline for a while. So if your first
> push doesn't make it through your push never works. It's likely to be rare, but
> painful when it happens and makes it feel unreliable.

When you are subscribing the push notifications your devices should be
running and not offline. Note, that you do not need reconfirmation if
you extended the time, but only when new URL is given. If client gives
url, it should make sure it can actually receive those notifications
in the given url for few seconds... 

>     It is really annoying trying to debug which firewall / proxy / encryption
>     is causing the notification to be blocked, if I need to reregister again
>     for every time and need to then somehow still cause one push notification
>     to be sent before I can see does it work. 
> 
> I'm not sure what you're referring to here. Do you mean the JMAP (application)
> server connecting to the push server? Or the push server connecting to the
> client (which is not part of JMAP at all, but where you're more likely to run
> into issues with corporate firewalls and the like)?

Perhaps my understanding of the jmap push service is then wrong, or
perhaps it is badly defined in JMAP. 

> My understanding is that is incorrect. There are three entities involved in an
> 8030 push system, and JMAP is only involved with two of them:
> 

But client and application server protocol is not defined in RFC8030.
It is left outside the scope of that document. RFC8030 seems to only
document interaction between the client and push service, and
interaction between application and push service.

The URL returned from the push service is somehow magically given to
the application server and whatever verification happens there is not
covered. 

> The situation of the client/application server being one entity and the push
> server being a completely unrelated entity is what 8030 is designed for. For
> example, each browser implements the Push API, whereby if you have a web app
> you can ask the browser for a push subscription endpoint, then send it to your
> application server to connect to. The application server does not know in
> advance which browser the user has or what domains that browser currently uses
> for push subscriptions. It simply gets given an arbitrary URL to post to.

Looking at the text in jmap. It says in section 7.2:

   A push subscription is a message delivery context established between
   the client and a push service.

Push service is not defined in this document, and it does not refer to
RFC8030 for that term. My understanding was that push worked as
follows:

Client does PushSubscription as defined in 7.2 to JMAP server:

   Clients may create a push subscription on the JMAP server, which will
   then make a POST request to the associated push endpoint whenever an
   event occurs.

This push subscription includes an url and when something happens the
JMAP server will connect to that url and send some random garbage
(from the receiver point of view if it does not assume receiveing push
notications) to it using POST. If the receiver end is proper push
service then it will notify the client using some other means.

I.e., when email etc is received the JMAP server will then push
StateChange object (section 7.1):

   When something changes on the server, the server pushes a
   *StateChange* object to the client.

Actually that says "to the client" not to the "push service". Which
one should it be? I always assumed this StateChange object is sent to
the url given in the PushSubscription.

Hmm... and 7.2 then also uses term "push endpoint" which is not
defined anywhere? Is that the same as push service at given url or
something else:

   Clients may create a push subscription on the JMAP server, which will
   then make a POST request to the associated push endpoint whenever an
   event occurs.

Then section 7.2 seems to also describe things not related to the
PushSubscription but instead to the notifications sent by the JMAP
server. Perhaps it would be better to move that to the StateChange
object section, i.e., put all things related to the "push service" in
same place. Now it is split in two places, i.e., StateChange is
defined in section 7.1, but how to transmit that inside https POST
with content type of application/json is described in 7.2.

Also it is not clear which server this is talking about:

							The server
   is expected to understand and handle HTTP status responses in a
   reasonable manner.

Is it push service server, JMAP server, Application server (same as
JMAP server in this case?). My guess it is supposed to be JMAP server
which is actually acting as http-client and making https request to
push service, and if push service returns http errors JMAP server
acting as http-client will process those in reasonable manner. Is that
understaning correct? Perhaps rewording it a bit to make it clear.

Then I have no idea what this text is trying to say:

   The use of this push endpoint conforms with the use of a push
   endpoint by an Application Server as defined in [RFC8030].

what push endpoint? JMAP server? URL given by the client to JMAP
server? 

> JMAP is not defining anything new here. It is just defining the application
> server portion exactly as expected by RFC8030.
> 
> Yes, this is how the client receives the data from the push server in RFC8030.
> This is entirely orthogonal to what we are discussing though.
> 
> Hmm, yes I see your point, although it seems odd for it not to mention at all
> given this is going to apply to pretty much every app that uses this system;
> not specifically JMAP.

Most likely it is not describied in the RFC8030 because the details
depends on the application server. 

> would be the only way to mitigate this.

I would expect it to be very easy to find urls in host that will
return success to http posts with application/json and ignore
contents.

> I would expect the JMAP server to rate limit the number of push
> subscriptions any one user may have to something considerably lower
> than that.

There is text saying frequency of pushes to be rate limited, but there
is no limit for number of subscriptions account can have, or even
suggestion that there should be limit.

This kind of attacks can also use multiple accounts especially if
there is some kind of public services available. 

> If the attacker had compromised many accounts on the JMAP
> server though, it could set up push subscriptions with each of them
> but then it would have to coordinate making a change in each of
> those accounts at the same time in order to flood the target server
> with a large single burst of requests, which is a much harder thing
> to do.

As people pointed out we have imap server providing access to ietf
mailing lists. There is lots of people on those lists, and even if we
require datatracker account to be able to make subscriptions, making
those accounts require just email address and ability to receive
emails. Most likely datatracker allows creating accounts for:

[email-masked]
[email-masked]
[email-masked]
...
[email-masked]

and then making subscription for all of those accounts to all ietf
mailing lists and sending notifications to same url x...

Verification step would disable that attack vector too. 

> Summing up, I think that adding a confirmation step removes a small
> risk of being able to use a JMAP application server as a DDOS
> vector, but adds a small risk of the push not being received and the
> push system failing to establish.

Actually I think it will make push system much more reliable, as it
immediately verifies that the system is working, and you will not have
silent failure, where you just notice few days later that I have not
received any notifications, something must be broken.

> (Although, the client would at least know this was the case so could
> alert the user and give them the option to try again.) Would anyone
> else like to weigh in on the relative merits of the options here to
> help come to a consensus on the way forward? I would be particularly
> interested to hear if this was discussed at all, and any conclusions
> reached, in the development of RFC8030.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 8 Jan 2019 16:49:02 +0200

Neil Jenkins writes:
> Err, not sure what you're talking about here. Most email systems
> already support sharing on a per-folder (or mailbox as they're
> called in IMAP and JMAP) granularity.

I have no idea how to do that for example in gmail. The imap server I
am running does not list support for 4314, and as I have never needed
such feature I have never checked if or how it can be done.

On the other hand I did not see any support for that in ipad or
android mail software either (or it might be well hidden in those
things, they are not very easy to use). 

> That's why JMAP and IMAP can return you a "myRights" object with
> your permissions for each mailbox. Calendars are identical; you
> generally share on a per-calendar basis (which acts the same as a
> mailbox for mail; a collection of individual data items).

Calendars usually have separate per item flag that tells whether event
is private, i.e., it is not only per calendar or per mailbox level.

Anyways, I have seen several cases where people share their personal
calendars, I have not seen cases where people share their personal
mailboxes. There cases where family members know other members
passwords, and can login if needed. Also group mailboxes, or reading
mail from multiple accounts in same mail software is very common,
sharing private mail boxes not so.

I.e., is it really common that:

      ... another user is sharing their mail with the logged in
      user,...

when not talking about group (support etc) or role (secretary) based
mail boxes?

If so, I am happy that I live in places where people do value
privacy, and I have not seen such things done... 
-- 
[email-masked]

---

From: Ned Freed <[email-masked]>
Date: Tue, 08 Jan 2019 08:04:29 -0800 (PST)

> untagged FETCH and EXPUNGE responses.

If IDLE was the same as NOOP then we wouldn't have added the IDLE command to
the protocol.

> Technically, they’re not actually

It's right there in the abstract:

   The Internet Message Access Protocol [IMAP4] requires a client to
   poll the server for changes to the selected mailbox (new mail,
   deletions).  It's often more desirable to have the server transmit
   updates to the client in real time.  This allows a user to see new
   mail immediately.  It also helps some real-time applications based on
   IMAP, which might otherwise need to poll extremely often (such as
   every few seconds).  (While the spec actually does allow a server to
   push EXISTS responses aysynchronously, a client can't expect this
   behaviour and must poll.)

Note the last sentence: If accepted IDLE requires that the server return
changes in mailbox state in real time. That opens the door to certain
types of traffic analysis.

Now, since the protocol does allow EXISTS responses to be pushed regardless
of IDLE, you can include RFC 3501 in having deficient security considerations
in this regard.

The fact remains that there's a missing security consideration here.

> for NOOP (that is, IMAP itself?

NOOP is pull and done at the client's discretion, IDLE is push and triggered
by server changes.

				Ned

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 08 Jan 2019 15:23:52 -0500

Ok - this is just getting silly.

*Tero:* is this something on which you feel strongly enough to block the progress of JMAP unless it's changed.

*Neil:* is this something which you feel strongly enough to insist on keeping?

If both of these are true, we need to keep debating this - otherwise, we can find a path forward on this particular point easily.

Cheers,

Bron.

On Wed, Jan 9, 2019, at 01:49, Tero Kivinen wrote:
> _______________________________________________
> Jmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jmap
>

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 08 Jan 2019 15:24:48 -0500

Sorry: I should clarify. By "this" I mean the wording in core mentioning mail as an example for isPersonal, not the existence of a mapping of RFC4314 into JMAP.

Bron.

---

From: "Neil Jenkins" <[email-masked]>
Date: Tue, 08 Jan 2019 21:19:50 -0500

On Tue, 8 Jan 2019, at 4:08 PM, Martin Thomson wrote:
> Rather than describe - in some detail - a defense that is questionable, I would simply limit this to the facts. 

Sure, agreed. I didn't mean to imply in any way that this was a comprehensive defence, and I agree it's better to just acknowledge the problem rather than give people a false sense of security. I have removed this second paragraph.

> Separately, you probably need to concern yourself with the push service as an attacker as well. There's more text on that in RFC 8030 if you care to cite that.

We already have the *Push encryption* subsection of the security considerations, which reads as follows. Is there something you would like to see that is still missing from this?

*When data changes, a small object is pushed with the new state strings for the types that have changed. While the data here is minimal, a passive man-in-the-middle attacker may be able to gain useful information. To ensure confidentiality and integrity, if the push is sent via a third party outside of the control of the client and JMAP server the client MUST specify encryption keys when establishing the PushSubscription and ignore any push notification received that is not encrypted and signed with those keys.**
*
*
*
*The privacy and security considerations of **RFC8030* <https://tools.ietf.org/html/rfc8030>* and **RFC8291* <https://tools.ietf.org/html/rfc8291>* also all apply to the use of the PushSubscription mechanism.*

Cheers,
Neil.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 09 Jan 2019 14:49:11 +1100

On Wed, Jan 9, 2019, at 13:19, Neil Jenkins wrote:
> *The privacy and security considerations of **RFC8030* 
> <https://tools.ietf.org/html/rfc8030>* and **RFC8291* 
> <https://tools.ietf.org/html/rfc8291>* also all apply to the use of the 
> PushSubscription mechanism.*

Yeah, that's good.  Just a case of not having done the search.  Sorry for the noise.

---

From: "Neil Jenkins" <[email-masked]>
Date: Tue, 08 Jan 2019 23:18:36 -0500

On Wed, 9 Jan 2019, at 1:28 AM, Tero Kivinen wrote:
> running and not offline.

Agreed. It's still possible for the initial message not to arrive, but in the vast majority of cases it will; if it doesn't, the client can destroy and recreate the subscription to try again. Weighing this up, I agree that adding a verification step is the best way forward here.

> one should it be?

Well, it's to the client, possibly via a push service, but possibly not because there are two "push" mechanisms defined here; the other is where the client can maintain a permanent TCP connection directly to the JMAP server in which case it can use an EventSource connection to receive push events directly without going via a 3rd party.

> defined anywhere? Is that the same as push service at given url

Reading through it again, there was some confusion in the use of terminology. I have rewritten a few sections to attempt to clarify this and the other confusing points you pointed out. You can see the changes for this here <https://github.com/jmapio/jmap/commit/27d21a4bca8187fc2cdd5561ccdda01bb6e26386>. The addition of a verification step is added in this change here <https://github.com/jmapio/jmap/commit/3d5e2ea288950a57670b4446f04dab9620e8bffa>.

Are you happy that this is sufficient to address your concerns?

Regards,
Neil.

---

From: "Neil Jenkins" <[email-masked]>
Date: Tue, 08 Jan 2019 23:26:37 -0500

> *Neil:* is this something which you feel strongly enough to insist on keeping?

I've gone back to the original email to try to see what the original comment was, before we digressed into arguing over whether people are able to share individual mailboxes or not. As far as I can see the paragraph that raised the issue was this in section 1.6.2:

*A single set of credentials may provide access to multiple accounts, for example if another user is sharing their mail with the logged in user, or if there is a group account.*

And Tero would like to see the word *mail* changed to *calendar*? I mean, sure that can work equally well as an example. I don't really see the need for the change, but if that resolves the issue I'm happy to change it. *Tero* – can you please let me know what change you are looking for if it's more than this.

Neil.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 24 Jan 2019 23:30:43 +0200

Neil Jenkins writes:
> Agreed. It's still possible for the initial message not to arrive, but in the
> vast majority of cases it will; if it doesn't, the client can destroy and
> recreate the subscription to try again. Weighing this up, I agree that adding
> a verification step is the best way forward here.
> 
> Well, it's to the client, possibly via a push service, but possibly not
> because there are two "push" mechanisms defined here; the other is where the
> client can maintain a permanent TCP connection directly to the JMAP server in
> which case it can use an EventSource connection to receive push events
> directly without going via a 3rd party.
> 
> Reading through it again, there was some confusion in the use of terminology.
> I have rewritten a few sections to attempt to clarify this and the other
> confusing points you pointed out. You can see the changes for this here. The
> addition of a verification step is added in this change here.
> 

Yes, I think this addresses my concerns about the denial of service
issues. The text also seems to make little bit more clear about the
terminology, and perhaps the Terminology section should refer to the
terms defined in the RFC8030, so it would be clear which terms comes
from there.

Sorry that it took so long to reply, but last week I was in the IEEE
meeting, thus I was not able to check these during that time.
-- 
[email-masked]

---

From: "Bron Gondwana" <[email-masked]>
Date: Thu, 24 Jan 2019 19:00:29 -0500

Thanks Tero - welcome back!

> meeting, thus I was not able to check these during that time.

Just to confirm - are you happy to clear your "has issues" now, or do you need further changes to the terminology reference first.

Thanks,

Bron.