6 ms·

I' m interested in this from a security perspective. What does this new protocol offer in terms of better control around what makes it to the inbox? Would IMAP>

I' m interested in this from a security perspective. What does this new protocol offer in terms of better control around what makes it to the inbox? Would IMAP>JMAP translation before hitting the user give us better ability to filter out malicious items/spam?

SwellJoe 12y ago
I think the only thing this particular protocol should be concerned with is reliably providing a method for communicating between client and server. Most spam and malicious mail filtering should happen as early in the process as possible, hopefully during the initial connection. There is a a protocol named Sieve ( http://www.ietf.org/rfc/rfc5228.txt http://www.ietf.org/rfc/rfc5228.txt ) which provides for delivery stage filtering rules. It is similar in capability and usage to procmail, but formalized and somewhat more modern (and not capable of running arbitrary system commands), and supported by some modern IMAP/POP servers, like Dovecot. Presumably if JMAP gets integrated into those servers, Sieve would also be available. And, I would hope there wouldn't be an IMAP/JMAP translation layer, but instead servers would implement JMAP directly. Though I guess in the short term there might be some sort of proxy.
- gecko 12y ago
  Sieve is the native filtering engine used by FastMail, so I'd say it integrates quite well with JMAP, from my experience. :)
groby_b 12y ago
So am I. From looking at http://jmap.io/spec.html#authentication http://jmap.io/spec.html#authentication, it looks like the password will be transmitted in plain text. (See the text below the 200 response) That makes me extremely queasy. Yes, HTTPS theoretically provides transport layer security, but a single breach of transport layer security results in the attackers permanent access to your mail. I.e. run a MITM attack in a coffee shop, snoop up JMAP passwords, make use of them at a latter point in time. I really hope I'm missing something important, or misread the spec.
- robn_fastmail 12y ago
  If you read the spec closely, you'll note that it provides support for arbitrary challenge/response auth mechanisms. Its conceptually the same as SASL in that respect. Yes, we're assuming a secure transport. Most of the internet currently does. Most of the passwords you send over encrypted channels right now are plaintext. This is not something we're trying to solve with JMAP (if it even needs solving, which is debatable).
  - illumen 12y ago
    Plain text passwords. No amount of blablabla can excuse that. Plain text passwords.
    - robn_fastmail 12y ago
      So all those services you use right now where you type in a password. How exactly are those passwords transmitted to the server?
      - mback2k 12y ago
        The plaintext password could probably be replaced by hashed passwords. Directly within the spec. Even though it already allows additional or different layers of security, this motivates developers to implement a basic level of security right into the application layer.
        icebraining 12y ago
        What prevents an attacker from using the hashed password (without decoding it) in his/her own requests?
        brongondwana 12y ago
        hashed passwords are security theatre unless you have a challenge-response in which password is hashed along with a challenge from the server, otherwise you don't need the password - you only need the hash to gain access. I've MITMed a system like that before when I wrote a nice interface to the awful timesheet system at a previous job. Mandating specific security mechanisms isn't future proof. Authentication is almost a side issue to JMAP itself. Getting a securely authenticated and protected channel is phase 1, sending and receiving the JMAP protocol items is phase 2. The reality is that almost everyone is sending plaintext passwords over SSL these days, and the reason isn't that they hate you - the reason is that it means they can bcrypt the password on the server side. An interesting factor about most of the challenge response protocols out there - the server side needs to know either the plaintext password or something pretty reversible about the plaintext password. That's how the server can have a little chat over the wire with your client about the shared secret that they both know. Since my security protocol design credentials aren't that much greater than the average internet commentator, I don't trust myself to design, or the average client writer to implement, a fancy security protocol that nobody has used before. Tried and true please.

SwellJoe 12y ago

I think the only thing this particular protocol should be concerned with is reliably providing a method for communicating between client and server. Most spam and malicious mail filtering should happen as early in the process as possible, hopefully during the initial connection. There is a a protocol named Sieve ( http://www.ietf.org/rfc/rfc5228.txt http://www.ietf.org/rfc/rfc5228.txt ) which provides for delivery stage filtering rules. It is similar in capability and usage to procmail, but formalized and somewhat more modern (and not capable of running arbitrary system commands), and supported by some modern IMAP/POP servers, like Dovecot. Presumably if JMAP gets integrated into those servers, Sieve would also be available. And, I would hope there wouldn't be an IMAP/JMAP translation layer, but instead servers would implement JMAP directly. Though I guess in the short term there might be some sort of proxy.

gecko 12y ago
Sieve is the native filtering engine used by FastMail, so I'd say it integrates quite well with JMAP, from my experience. :)

groby_b 12y ago

So am I. From looking at http://jmap.io/spec.html#authentication http://jmap.io/spec.html#authentication, it looks like the password will be transmitted in plain text. (See the text below the 200 response) That makes me extremely queasy. Yes, HTTPS theoretically provides transport layer security, but a single breach of transport layer security results in the attackers permanent access to your mail. I.e. run a MITM attack in a coffee shop, snoop up JMAP passwords, make use of them at a latter point in time. I really hope I'm missing something important, or misread the spec.

robn_fastmail 12y ago
If you read the spec closely, you'll note that it provides support for arbitrary challenge/response auth mechanisms. Its conceptually the same as SASL in that respect. Yes, we're assuming a secure transport. Most of the internet currently does. Most of the passwords you send over encrypted channels right now are plaintext. This is not something we're trying to solve with JMAP (if it even needs solving, which is debatable).
- illumen 12y ago
  Plain text passwords. No amount of blablabla can excuse that. Plain text passwords.
  - robn_fastmail 12y ago
    So all those services you use right now where you type in a password. How exactly are those passwords transmitted to the server?
    - mback2k 12y ago
      The plaintext password could probably be replaced by hashed passwords. Directly within the spec. Even though it already allows additional or different layers of security, this motivates developers to implement a basic level of security right into the application layer.
      - icebraining 12y ago
        What prevents an attacker from using the hashed password (without decoding it) in his/her own requests?
      - brongondwana 12y ago
        hashed passwords are security theatre unless you have a challenge-response in which password is hashed along with a challenge from the server, otherwise you don't need the password - you only need the hash to gain access. I've MITMed a system like that before when I wrote a nice interface to the awful timesheet system at a previous job. Mandating specific security mechanisms isn't future proof. Authentication is almost a side issue to JMAP itself. Getting a securely authenticated and protected channel is phase 1, sending and receiving the JMAP protocol items is phase 2. The reality is that almost everyone is sending plaintext passwords over SSL these days, and the reason isn't that they hate you - the reason is that it means they can bcrypt the password on the server side. An interesting factor about most of the challenge response protocols out there - the server side needs to know either the plaintext password or something pretty reversible about the plaintext password. That's how the server can have a little chat over the wire with your client about the shared secret that they both know. Since my security protocol design credentials aren't that much greater than the average internet commentator, I don't trust myself to design, or the average client writer to implement, a fancy security protocol that nobody has used before. Tried and true please.