3 ms·

What is a worthwhile replacement to DNS? We don't have one. That's part of the problem: differences of opinion. Try HTTP/HTTPS: we have separate ports, browser

What is a worthwhile replacement to DNS? We don't have one. That's part of the problem: differences of opinion. Try HTTP/HTTPS: we have separate ports, browser preferences, and lots of unified messaging deprecating HTTP. Suppose we reuse the same format (name@dom). What would a migration plan look like? Early stages: - DNS record indicating support. - Separate ports. - Reduced spam (because nobody is using it). - No warning messages. Mid stage: - Lots of dual-stack systems. - Something like HSTS and preloading. - Warning indicating insecure delivery (the client can detect this). - Buy-in from most large corps (Gmail...) Late stages: - Old, insecure port goes away almost entirely. - Revisions to spec, improvements. We're still at the tail end of this for HTTPS, and we're building on top of a well-known, supported encryption protocol (TLS, which gets reused elsewhere). The point is, if Gmail doesn't buy in, you've not made meaningful progress, because they have billions of users alone. And unless they move, most large corps/... won't also move. That's, in my opinion, why Signal and stuff (while nice, secure, ....), won't replace email. So how do we get there? First we need a security protocol with the constraints outlined in the post. - Forward secrecy, - Handles key rotations, - Notifies of device changes potentially. - ... That's going to take time to design, develop, and standardize. Whether we tie the messaging protocol and format (SMTP/...) tightly to the security protocol (TLS) remains to be seen. It takes time for formal verification too. Then we need Gmail support. If it is a closed, non-standard protocol (like Signal), it won't be adopted. The RFC process is the only process I know that can influence those types of changes. And yeah, now? It won't be secure. But we'll have a path from getting to "mostly plaintext" to "mostly secure". And we'll have to live with the fact that it takes time. If you're not reusing the same address scheme, then yeah. You would have to educate a lot of people about the difference. But if you push that onto the developers, I think that's better. And you can make it mostly transparent to the end user, except at critical times.

rjzzleep 7y ago
Can we also stop pretending Signal was some genius stroke that happened in a vacuum? With all due respect to Moxie signal was born out of years of experience with OTR and SCIMP for XMPP and the need for asynchronous key exchanges in chat systems.
- tptacek 7y ago
  Moxie Marlinspike and Trevor Perrin.
- lvh 7y ago
  Sure: is there a specific place where you feel I've done that? I think everyone involved would happily concede that Signal, like almost everything, stood on the shoulders of giants. It seems fine to both acknowledge that and also say that making it more accessible (literally go install this thing from the app store) and developing it further (the Signal protocol builds on OTR and SCIMP, sure, but Axolotl, 3XDH and the formalization of Noise are meaningful developments that also warrant recognition).
thedufer 7y ago
The thing that's hard to swallow is that you're recommending a plan that maybe solves the problem by 2050. Remember, STARTTLS was standardized 22 years ago and you still can't reject emails from servers that don't use it unless you're okay with missing business-critical messages, in my experience. Meanwhile, Signal works today. It would be cool if there was a group working on the solution you've laid out, and maybe it'll still be relevant when it arrives, but if you have any privacy needs before you retire we have to point you at Signal.
- cipherboy 7y ago
  Sure, but HTTP was started in '97, and yet we've gotten a decent replacement rate towards HTTPS. It's all about publicity and messaging. We made an explicit, coordinated push to get rid of HTTP. We're still working on it. Think of how many people were/are involved. We've not had a coordinated push for SMTP. TLS doesn't satisfy anything but a trivial threat and trust model (for secure messaging, when done at the SMTP layer). And that would involve a lot less people if we get it "right" (and it's only a new protocol and not a new app). If it were up to me (it's not), we'd have a solid technical spec and then try and make this happen. Rather than pushing STARTTLS. There is kinda a group working on a solution. I don't know what the current status is and what their funding levels are: https://darkmail.info/ https://darkmail.info/ For these purposes, the branding is all wrong. I've not read a recent version of the spec, but there's still commits as of 6 months ago.
  - thedufer 7y ago
    Sure, but it seems to me that improving email is more similar to improving email than to improving HTTP. I think the STARTTLS push has gone more slowly than HTTPS for reasons that are fairly fundamental to email - it requires hitting more providers to get decent coverage. Chrome has >60% market share, while GMail is <30%.

rjzzleep 7y ago

Can we also stop pretending Signal was some genius stroke that happened in a vacuum? With all due respect to Moxie signal was born out of years of experience with OTR and SCIMP for XMPP and the need for asynchronous key exchanges in chat systems.

tptacek 7y ago
Moxie Marlinspike and Trevor Perrin.
lvh 7y ago
Sure: is there a specific place where you feel I've done that? I think everyone involved would happily concede that Signal, like almost everything, stood on the shoulders of giants. It seems fine to both acknowledge that and also say that making it more accessible (literally go install this thing from the app store) and developing it further (the Signal protocol builds on OTR and SCIMP, sure, but Axolotl, 3XDH and the formalization of Noise are meaningful developments that also warrant recognition).

thedufer 7y ago

The thing that's hard to swallow is that you're recommending a plan that maybe solves the problem by 2050. Remember, STARTTLS was standardized 22 years ago and you still can't reject emails from servers that don't use it unless you're okay with missing business-critical messages, in my experience. Meanwhile, Signal works today. It would be cool if there was a group working on the solution you've laid out, and maybe it'll still be relevant when it arrives, but if you have any privacy needs before you retire we have to point you at Signal.

cipherboy 7y ago
Sure, but HTTP was started in '97, and yet we've gotten a decent replacement rate towards HTTPS. It's all about publicity and messaging. We made an explicit, coordinated push to get rid of HTTP. We're still working on it. Think of how many people were/are involved. We've not had a coordinated push for SMTP. TLS doesn't satisfy anything but a trivial threat and trust model (for secure messaging, when done at the SMTP layer). And that would involve a lot less people if we get it "right" (and it's only a new protocol and not a new app). If it were up to me (it's not), we'd have a solid technical spec and then try and make this happen. Rather than pushing STARTTLS. There is kinda a group working on a solution. I don't know what the current status is and what their funding levels are: https://darkmail.info/ https://darkmail.info/ For these purposes, the branding is all wrong. I've not read a recent version of the spec, but there's still commits as of 6 months ago.
- thedufer 7y ago
  Sure, but it seems to me that improving email is more similar to improving email than to improving HTTP. I think the STARTTLS push has gone more slowly than HTTPS for reasons that are fairly fundamental to email - it requires hitting more providers to get decent coverage. Chrome has >60% market share, while GMail is <30%.