Re: [Jmap] JMAP security

[Yoav Nir <[e-mail]>]

Hi, Dmitry.

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

> Hello, Yoav.
> 
> Четверг, 9 февраля 2017, 0:01 +05:00 от Yoav Nir <[e-mail]>:
> 
> 
> On 8 Feb 2017, at 19:28, podkorytov <[e-mail] <mailto:[e-mail]>> wrote:
>> Hello, what about JMAP client security ?
>> 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.
> 
> 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.
>   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.
>> 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.
> 
> 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 ?

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.

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

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