5 ms·

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

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...
    - icebraining 12y ago
      I don't think that's very relevant for this use case, though - JMAP is clearly intended for use by custom clients, not browsers, and those can use SSL with a completely different model from the CA scheme, including bundling certs for the most popular providers (similar to HSTS preload lists).
    - feld 12y ago
      Everyone has noticed. This cannot be solved overnight and rolled out to the entire planet. Stop beating this dead horse.

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...
  - icebraining 12y ago
    I don't think that's very relevant for this use case, though - JMAP is clearly intended for use by custom clients, not browsers, and those can use SSL with a completely different model from the CA scheme, including bundling certs for the most popular providers (similar to HSTS preload lists).
  - feld 12y ago
    Everyone has noticed. This cannot be solved overnight and rolled out to the entire planet. Stop beating this dead horse.