4 ms·

Why would you create a new email protocol without an encryption requirement? I understand trying to fix the existing protocol problems but one of the biggest is

Why would you create a new email protocol without an encryption requirement? I understand trying to fix the existing protocol problems but one of the biggest is plaintext.

brongondwana 12y ago
Because SSL does the job of securing data between the server and the client just fine. There are a ton of interesting problems in the email world, including all the server to server communications. JMAP is lightning focused on solving ONE of those problems - the communication between end-user devices and their mail server - and doing it well.
- mikhailt 12y ago
  You're assuming SSL is implemented without any security bugs. We saw what happened with Heartbleed and when SSL implementations are not properly reviewed and updated by a full funded team.
  - nmjenkins 12y ago
    So you're assuming that an independent encryption layer that has to be reimplemented by every email client dev is going to be more secure than a widely studied protocol, implemented at the OS level. Right…
    - mikhailt 12y ago
      No, I'm not assuming anything and didn't even say anything like that. My point is that using SSL on its own as the only line of defense should not be an excuse not to have anything else. It's like saying my apartment doesn't have a spec for a security system nor a safe because the lock on the door does enough of a job to secure it. Also, a widely studied protocol spec means nothing. The bugs are from the humans coding the implementations, it doesn't matter what level it is, they will have some bugs. Nobody can code a perfect secure implementation but we can have some kind of redundancies in the system, where if one security level fails, the rest can still have some reasonable security left. Relying on SSL alone is not enough. But I don't think JMAP is the right place to do this, we may need something else in addition to JMAP. At least JMAP is extendable, so that's one good thing it has.
      - schrodinger 12y ago
        What would you recommend then?
        mikhailt 12y ago
        No clue at the moment, this is still a big problem and something Fastmail already knows based on the comment here from robn_fastmail. If we have a solution, everybody would be using it by now. PGP or SIME was going to be it back in 90s but it didn't take off well. The content of the message itself should be encrypted at the very least but how do you deal with the keys then?
      - brongondwana 12y ago
        If SSL is broken, you are - as many people have noticed, screwed. JMAP itself is entirely encryption layer agnostic. It's transport layer agnostic. JMAP over HTTPS is definitely going to be the first layer, but we're looking at websockets with interest as well. If you were insane, you could do JMAP over XMPP, or JMAP over email. That would be neatly recursive...
        mikhailt 12y ago
        Exactly what I was trying to say but likely did it wrong. I rather have a secure modular system than a single protocol that does everything. We simply just can't leave it as JMAP+SSL because once SSL cannot be trusted, it should be easier to replace it with a better solution or an updated SSL protocol. I don't think it is reasonable to include this within JMAP and force all services to update jMAP overnight because the internal crypto library had a hole.
        uaygsfdbzf 12y ago
        In case you hadn't noticed, the authenticity model of SSL was an afterthought and is completely broken. I recommend listening to Moxie's talk about this: https://www.youtube.com/watch?v=pDmj_xe7EIQ https://www.youtube.com/watch?v=pDmj_xe7EIQ http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/ http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authe...
robn_fastmail 12y ago
Its expected that you'll run JMAP over HTTPS which takes care of the wire encryption. For end-to-end encryption, there's a heap of problems that still aren't solved (key distribution, need for content analysis). There's no reason JMAP couldn't be extended in the future to support these via additional properties, attached encrypted payloads, etc but mandating it from the outset would quickly see the whole protocol dead before it began.
- davexunit 12y ago
  >key distribution GPG key servers?
  - robn_fastmail 12y ago
    And how do you trust those? And if I'm a brand new user, how do I get my key in there? All the moving parts probably exist, but so far no one has pulled it together into something that a random person off the street can use. Its not the problem JMAP is trying to solve.
    - uaygsfdbzf 12y ago
      You don't need to trust the keyservers since you verify the fingerprints of downloaded keys against the fingerprints given to you in person. The keyserver protocol includes commands to include keys in the keyserver network. How you send keys depends on the UI of the tool you use, geeks will do this: gpg --keyserver <keyserver> --send-keys <fingerprint>
      - robn_fastmail 12y ago
        Right. I'm a little rusty on the details. My point stands - key distribution is not a solved problem for the average user.
        uaygsfdbzf 12y ago
        It is solved for some specific platforms, GNOME for example: https://mail.gnome.org/archives/gnome-announce-list/2014-November/msg00004.html https://mail.gnome.org/archives/gnome-announce-list/2014-Nov... The average user doesn't use GNOME or Linux though :(
tadfisher 12y ago
That presents an interesting problem: can any implementation of a communication protocol enforce a requirement that arbitrary payloads are cyphertext?
geofft 12y ago
This is for the client to speak to the mailstore, where plaintext is often not a problem. In many cases, it's a feature: if I forget my password, I'd like to be able to recover access to my email; at a company, I'd like authorized sysadmins to be able to get to other people's email, etc. If you were designing a replacement for server-to-server SMTP, it'd be nice to require encryption, possibly end-to-end encryption.... although encryption can also be layered on top, at the RFC 822 level instead of the RFC 821 one (as S/MIME, PGP, etc. do). But this isn't an SMTP replacement, it's a replacement for IMAP (and ActiveSync, POP3, etc.).

Why would you create a new email protocol without an encryption requirement? I understand trying to fix the existing protocol problems but one of the biggest is plaintext.

brongondwana 12y ago

Because SSL does the job of securing data between the server and the client just fine. There are a ton of interesting problems in the email world, including all the server to server communications. JMAP is lightning focused on solving ONE of those problems - the communication between end-user devices and their mail server - and doing it well.

mikhailt 12y ago
You're assuming SSL is implemented without any security bugs. We saw what happened with Heartbleed and when SSL implementations are not properly reviewed and updated by a full funded team.
- nmjenkins 12y ago
  So you're assuming that an independent encryption layer that has to be reimplemented by every email client dev is going to be more secure than a widely studied protocol, implemented at the OS level. Right…
  - mikhailt 12y ago
    No, I'm not assuming anything and didn't even say anything like that. My point is that using SSL on its own as the only line of defense should not be an excuse not to have anything else. It's like saying my apartment doesn't have a spec for a security system nor a safe because the lock on the door does enough of a job to secure it. Also, a widely studied protocol spec means nothing. The bugs are from the humans coding the implementations, it doesn't matter what level it is, they will have some bugs. Nobody can code a perfect secure implementation but we can have some kind of redundancies in the system, where if one security level fails, the rest can still have some reasonable security left. Relying on SSL alone is not enough. But I don't think JMAP is the right place to do this, we may need something else in addition to JMAP. At least JMAP is extendable, so that's one good thing it has.
    - schrodinger 12y ago
      What would you recommend then?
      - mikhailt 12y ago
        No clue at the moment, this is still a big problem and something Fastmail already knows based on the comment here from robn_fastmail. If we have a solution, everybody would be using it by now. PGP or SIME was going to be it back in 90s but it didn't take off well. The content of the message itself should be encrypted at the very least but how do you deal with the keys then?
    - brongondwana 12y ago
      If SSL is broken, you are - as many people have noticed, screwed. JMAP itself is entirely encryption layer agnostic. It's transport layer agnostic. JMAP over HTTPS is definitely going to be the first layer, but we're looking at websockets with interest as well. If you were insane, you could do JMAP over XMPP, or JMAP over email. That would be neatly recursive...
      - mikhailt 12y ago
        Exactly what I was trying to say but likely did it wrong. I rather have a secure modular system than a single protocol that does everything. We simply just can't leave it as JMAP+SSL because once SSL cannot be trusted, it should be easier to replace it with a better solution or an updated SSL protocol. I don't think it is reasonable to include this within JMAP and force all services to update jMAP overnight because the internal crypto library had a hole.
      - uaygsfdbzf 12y ago
        In case you hadn't noticed, the authenticity model of SSL was an afterthought and is completely broken. I recommend listening to Moxie's talk about this: https://www.youtube.com/watch?v=pDmj_xe7EIQ https://www.youtube.com/watch?v=pDmj_xe7EIQ http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/ http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authe...

robn_fastmail 12y ago

Its expected that you'll run JMAP over HTTPS which takes care of the wire encryption. For end-to-end encryption, there's a heap of problems that still aren't solved (key distribution, need for content analysis). There's no reason JMAP couldn't be extended in the future to support these via additional properties, attached encrypted payloads, etc but mandating it from the outset would quickly see the whole protocol dead before it began.

davexunit 12y ago
>key distribution GPG key servers?
- robn_fastmail 12y ago
  And how do you trust those? And if I'm a brand new user, how do I get my key in there? All the moving parts probably exist, but so far no one has pulled it together into something that a random person off the street can use. Its not the problem JMAP is trying to solve.
  - uaygsfdbzf 12y ago
    You don't need to trust the keyservers since you verify the fingerprints of downloaded keys against the fingerprints given to you in person. The keyserver protocol includes commands to include keys in the keyserver network. How you send keys depends on the UI of the tool you use, geeks will do this: gpg --keyserver <keyserver> --send-keys <fingerprint>
    - robn_fastmail 12y ago
      Right. I'm a little rusty on the details. My point stands - key distribution is not a solved problem for the average user.
      - uaygsfdbzf 12y ago
        It is solved for some specific platforms, GNOME for example: https://mail.gnome.org/archives/gnome-announce-list/2014-November/msg00004.html https://mail.gnome.org/archives/gnome-announce-list/2014-Nov... The average user doesn't use GNOME or Linux though :(

tadfisher 12y ago

That presents an interesting problem: can any implementation of a communication protocol enforce a requirement that arbitrary payloads are cyphertext?

geofft 12y ago

This is for the client to speak to the mailstore, where plaintext is often not a problem. In many cases, it's a feature: if I forget my password, I'd like to be able to recover access to my email; at a company, I'd like authorized sysadmins to be able to get to other people's email, etc. If you were designing a replacement for server-to-server SMTP, it'd be nice to require encryption, possibly end-to-end encryption.... although encryption can also be layered on top, at the RFC 822 level instead of the RFC 821 one (as S/MIME, PGP, etc. do). But this isn't an SMTP replacement, it's a replacement for IMAP (and ActiveSync, POP3, etc.).