Subject: [Jmap] JMAP security

From: podkorytov <[email-masked]>
Date: Wed, 08 Feb 2017 22:28:48 +0500

Hello, what about JMAP client security ? 
If it will works inside web browser it can inherit it vulneriabilities and join own, 
Any browser plugins such as Adobe's or something else may be potencial hole and targets for attacks. 
Probably it question out of frames of protocol draft , but it practical thing ang may to influence on JMAP success or fail. It will works inside browser with many others web applications and pluginses.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 8 Feb 2017 21:01:10 +0200

> If it will works inside web browser it can inherit it vulneriabilities and join own,
JMAP is (will be?) a protocol. It can be implemented in Javascript in a browser; it can be implemented as part of a desktop or mobile MUA; it can be implemented as a library for use by servers that send email.
> Any browser plugins such as Adobe's or something else may be potencial hole and targets for attacks.
Since we do expect browser use, that is definitely something to consider.  Preventing plug-ins and scripts running in other tabs from sending requests on behalf of the user should certainly be a goal for the protocol.  There are some ways of doing that: authenticating each HTTP request with something better than session cookies, making the resource names unpredictable, etc. That is definitely part of the design.
> Probably it question out of frames of protocol draft , but it practical thing ang may to influence on JMAP success or fail. It will works inside browser with many others web applications and plug-ins
> 
Security considerations are part of every IETF document and discussion of security vulnerabilities within the operating environment are very much in scope.

Yoav

---

From: Дмитрий Подкорытов <[email-masked]>
Date: Thu, 09 Feb 2017 19:33:48 +0300

Hello, Yoav.

>Четверг,  9 февраля 2017, 0:01 +05:00 от Yoav Nir <[email-masked]>:
>
>
>On 8 Feb 2017, at 19:28, podkorytov < [email-masked] > wrote:
Right, client for JMAP can be designed in  different styles, but for working over HTTP 
,to be frank,  is more easy to get something like browser or well known HTTP libs and remove useless code from it.
  O therwise , writing communicating by HTTP/HTTPS from ground level may be more difficult , than writing from zero level IMAP or POP3 client.

>Security considerations are part of every IETF document and discussion of security vulnerabilities within the operating environment are very much in scope.
Stateless protocols sometimes may be on MITM attack, somebody is able to catch TCP packet from JMAP client and repeat it many times. 
All needed for authorization already inside this single packet, right ?
Destination in this case will be under DoS attack. What is planning in JMAP for preventing such things ?
Maybe random field in JSON structure or time stamp with high precision?

>
>Yoav
>
>_______________________________________________
>Jmap mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/jmap

Dmitrii Podkorytov

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 9 Feb 2017 16:44:57 +0000

Hi Дмитрий,

On 09/02/2017 16:33, Дмитрий Подкорытов wrote:
>     On 8 Feb 2017, at 19:28, podkorytov <[email-masked]
>     <mailto:[email-masked]>> wrote:
>

>     Since we do expect browser use, that is definitely something to
>     consider.  Preventing plug-ins and scripts running in other tabs
>     from sending requests on behalf of the user should certainly be a
>     goal for the protocol.  There are some ways of doing that:
>     authenticating each HTTP request with something better than
>     session cookies, making the resource names unpredictable, etc.
>     That is definitely part of the design.
>>
>>     Probably it question out of frames of protocol draft , but it
>>     practical thing ang may to influence on JMAP success or fail. It
>>     will works inside browser with many others web applications and
>>     plug-ins
>>
>     Security considerations are part of every IETF document and
>     discussion of security vulnerabilities within the operating
>     environment are very much in scope.
>
>
> Stateless protocols sometimes may be on MITM attack, somebody is able 
> to catch TCP packet from JMAP client and repeat it many times.
JMAP should be running over HTTPS, which should make it much more difficult.

Best Regards,
Alexey

---

From: Yoav Nir <[email-masked]>
Date: Thu, 9 Feb 2017 19:07:40 +0200

Hi, Dmitry.

On 9 Feb 2017, at 18:33, Дмитрий Подкорытов <[email-masked]> wrote:

> On 8 Feb 2017, at 19:28, podkorytov <[email-masked] <mailto:[email-masked]>> wrote:
>   Otherwise, writing communicating by HTTP/HTTPS from ground level may be more difficult , than writing from zero level IMAP or POP3 client.

Developers are not faced with the choice of either in-browser or writing on top of libc. I wouldn’t write it from the ground up. If using python I’d use the urllib, json, and ssl modules and then all that remains for me is constructing the objects according to the standard. In C++ I might use libcurl and jsoncpp.  Other languages have their equivalents.

The session maintenance and request authentication mechanisms that will be in JMAP may or may not be mechanisms that are already implemented in these libraries, but this is true regardless of platform. Developers will choose a platform based on what they want to develop, not based on what platform is marginally easier. EWS works fine in desktop MUAs.
> All needed for authorization already inside this single packet, right ?

Those are addressed by TLS. JMAP has to run over HTTPS, and not just because of these attacks. It’s email. Privacy is not optional.

> Maybe random field in JSON structure or time stamp with high precision?

A JMAP server is subject to all the DoS attacks that any other HTTPS server is subject to. In fact, I don’t think SMTP or IMAP are any different if they’re using TLS.

Yoav

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 9 Feb 2017 18:32:36 +0100

It sounds like a straightforward origin problem. Perhaps the security 
considerations should mention the origin headers. Or they may do 
already, that is the kind of near-boilerplate I would hardly even 
notice.

Arnt