Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JMAP – a better way to email

blog.fastmail.com

Post reply on HN
Print view View original

101–110 of 116 posts

Re: JMAP – a better way to email

#101

Post by brongondwana »

mback2k wrote: post #96
robn_fastmail wrote: post #90

Earlier quoted context omitted.

So all those services you use right now where you type in a password. How exactly are those passwords transmitted to the server?

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.

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.

Re: JMAP – a better way to email

#102

Post by brongondwana »

nona wrote: post #94
nmjenkins wrote: post #72

Earlier quoted context omitted.

Each call is tagged by the client and the same tag is added to the response by the server, so you can tell exactly what error corresponds to which call. Caching is pretty easy: you just keep a cache of each object type. The delta update mechanism means you can very accurately invalidate what you need to keep it up to date. The system is actually really flexible and a great fit for any CRUD based app; JMAP is really j…

Oh right, now I see the: ["error", { type: "unknownMethod"}, "client-id"] -bit. Still, it sounds like you're reinventing HTTP verbs and statuscodes and embedding them inline in the JSON just to be able to multiplex the calls. Might as well use HTTP2 or SPDY, then. Also, caching JMAP may be easy on the client side, but not for any intermediate cache - unless it understands JMAP. I'm not saying RPC over HTTP is bad, mi…

Approximately nobody likes having intermediate caches that can cache their https traffic.

Approximately even fewer of the people here at HN like the idea of their email messages behing sent over non-secure channels.

At least we're not embedding HTTP status codes in XML...

Re: JMAP – a better way to email

#103

Post by feld »

sukh wrote: post #74
veb wrote: post #56

Earlier quoted context omitted.

Ha. I'm the same, every time I read about them I want to make the jump - but I'm not reliant on any of those, except mail fortunately. I just haven't quite done it yet. From people I've spoken to, everyone praises Fastmail... seems like we all need that extra push.

Less than pleasant first experience. Card failed, reason never communicated clearly enough. Very slow and archaic support.

I've had bugs reported, confirmed, and patched in production in less than 48hrs multiple times.

Slow?

Re: JMAP – a better way to email

#104

Post by feld »

uaygsfdbzf wrote: post #82
brongondwana wrote: post #67

Earlier quoted context omitted.

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

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 http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authe...

Everyone has noticed. This cannot be solved overnight and rolled out to the entire planet. Stop beating this dead horse.

Re: JMAP – a better way to email

#105

Post by feld »

Animats wrote: post #73

What does this do that IMAP and SMTP don't do already? All you need is an IMAP server, accessed from all your devices. The one that comes with Android isn't bad. Thunderbird works fine on the desktop. You don't have to use GMail with Android; when you first power up your Android device, click "Later" when it asks for a Google login. Then delete the Google One-Time Startup app. Google won't bother you again.

IMAP is a terrible protocol. It's a poorly designed filesystem with all the baggage that comes with it. Read the IMAP overview in the IMAP ruby module -- it's disgusting and was never meant for the modern world.

http://rxr.whitequark.org/mri/source/lib/net/imap.rb

Re: JMAP – a better way to email

#106

Post by feld »

maxk42 wrote: post #59
ricardobeat wrote: post #30

Earlier quoted context omitted.

How is this different from adding an address to your blacklist after the first message?

They can't deliver their spam message to begin with. You'd need to approve the contact then you could still block them if they spam you. There's still friend-request spam on facebook, but not nearly as much as email because you can just ignore the people you don't know and block people you do know if they begin to spam you.

The request for contact would be just as bad as the spam itself...

Re: JMAP – a better way to email

#107

Post by groby_b »

robn_fastmail wrote: post #52
groby_b wrote: post #51

Earlier quoted context omitted.

So am I. From looking at 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 pa…

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 debat…

I wouldn't ask you to solve it. I would've hoped for simply deferring the problem to somebody else. (I.e. OAuth)

Authentication is an incredibly hard problem. Including it in the spec encumbers it. And allowing for arbitrary challenge/response auth mechanisms gains you exactly one thing - guaranteed incompatibility as the protocol gains popularity :)

Re: JMAP – a better way to email

#108

Post by groby_b »

brongondwana wrote: post #101
mback2k wrote: post #96

Earlier quoted context omitted.

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.

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 almo…

Mostly agree with you, but minor nit: The server doesn't need to know anything reversible about the password. A message digest is enough.

And your final paragraph is the reason I posted my original comment in the first place. Don't design a auth/security protocol when you design a mail protocol. Delegate to OAuth, move on. (Then again... debate rages there, too[1]. Auth is not fun(tm))

[1] http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-h...

Re: JMAP – a better way to email

#109

Post by Animats »

corford wrote: post #75
Animats wrote: post #73

What does this do that IMAP and SMTP don't do already? All you need is an IMAP server, accessed from all your devices. The one that comes with Android isn't bad. Thunderbird works fine on the desktop. You don't have to use GMail with Android; when you first power up your Android device, click "Later" when it asks for a Google login. Then delete the Google One-Time Startup app. Google won't bother you again.

tldr; version: It reduces the number of network roundtrips (and server overhead) needed to keep clients in sync (great for mobile) and addresses the fragmentation issue between the various server & client implementations of the sprawling IMAP protocol. By moving to JSON and HTTP it also makes the barrier to entry a lot lower for client developers and opens up the possibility to improve speed yet further with GZIP and…

The Ruby version of the IMAP client isn't that bad. Yes, IMAP doesn't use the current fad for marshaling, JSON. But a few years ago the web crowd would have wanted XML, and a few years from now they'll probably want some binary protocol Google comes up with. "Gzip" compression isn't a big win for objects the size of email messages, anyway.

IMAP servers that don't use a real database are sure to be a mess, but that's not the fault of the protocol.

I'd rather not have some startup in the middle of the mail chain. They'll start thinking they own mail.

Re: JMAP – a better way to email

#110

Post by brerlapn »

groby_b wrote: post #107
robn_fastmail wrote: post #52

Earlier quoted context omitted.

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 debat…

I wouldn't ask you to solve it. I would've hoped for simply deferring the problem to somebody else. (I.e. OAuth) Authentication is an incredibly hard problem. Including it in the spec encumbers it. And allowing for arbitrary challenge/response auth mechanisms gains you exactly one thing - guaranteed incompatibility as the protocol gains popularity :)

Having worked in identity management and access control, I can't emphasize enough how important your second paragraph is, and why Fastmail's approach of leaving authentication out of the protocol is the right way to go. Over and over we run into solutions that are borked from the start because they have a basic, bare-bones authentication component that is included because customers expect to be able to log in "out of the box" but then can't be replaced with a sophisticated authentication module because that basic bare-bones piece has its crappy insecure tendrils entwined throughout the rest of the product. Mikhailt said it in this discussion, too--modular components that do their single job well, and don't cram them all into one protocol.
Post reply on HN