[Cryptography] Email and IM are ideal candidates for mix networks

Jerry Leichter leichter at lrw.com
Sun Aug 25 23:32:32 EDT 2013


On Aug 25, 2013, at 7:04 PM, Christian Huitema wrote:

> I think we can agree that the first step is to deploy home servers, and that
> the first application there would  to host communication applications. Just
> doing that without much other change would already provide protection
> against the "silent spying" that goes on in big cloud servers.
> 
> Initial deployment of anything must provide an immediate reward to the early
> adopters. You cannot rely on a network effect, and that means you can
> certainly not request third parties to adopt a new protocol. So better pinch
> our noses and say that, of course, we will accept SMTP mail. Probably SIP as
> well, and XMPP. We just need at first to make sure that the home server is
> easy to deploy and maintain. Then the adopters get the immediate reward,
> "nobody can go through my mail archives without asking me."
I agree, and have suggested this as the right "next step" for a couple of years.  (For services like mail, it's the right next step *even without the security considerations*.  At one time, everyone who wanted to run use mail ran his own mail server.  This was a pain to do, and didn't work well in a world of intermittent network connectivity and small disks.  Letting someone else figure out how to keep sendmail working, provide a continuous on-line presence, back up the disks, and so on, was a clear win.

Today, however, pretty much everyone (well, at least in the first world; but the problems elsewhere are of an entirely different nature anyway) has a continuous, immensely fast (relative to the demands of mail) internet connection, disk is "too cheap to meter", machines run of years with no maintenance, and you can back everything up using readily-available tools to encrypted copies in the cloud, or on friend's system.  What's been missing is the ability to configure your local mail server as easily as you set up an email address at Google or Yahoo or at any other provider.  But that's a solvable problem.

On the flip side, mail systems like gMail or Yahoo mail are complex and difficult to run *exactly because they are immense*.  But what are they getting for that size?  There are no economies of scale here - in fact, there are clear *dis*economies.

Even without the recent uproar over email privacy, at some point, someone was going to come up with a product along the following lines:  Buy a cheap, preconfigured box with an absurd amount of space (relative to the "huge" amounts of space, like 10GB, the current services give you); then sign up for a service that provides your MX record and on-line, encrypted backup space for a small monthly fee.  (Presumably free services to do the same would also appear, perhaps from some of the dynamic DNS providers.)  What's the value add of one of the giant providers?

> The various P2P enhancements come next, once there already is a network of
> home servers. The obvious one is a communication application that beats
> traffic analysis by embedding its own "shuffling" or "onion routing."
A single-purpose appliance - a box that has exactly two open ports on the Internet, one for SMTP and one for IMAP, with management over a physically separate interface, would have a tiny attack surface and could be very secure.  The more interfaces you put on the box, the less secure it gets.

Maybe you can play games with virtualization - not the kind of virtualization that's used today, with all kinds of hooks for efficient sharing, but virtualization specifically for security, with as little sharing as possible (e.g., completely separate virtual disks; so what if you duplicate stuff, programs and such are tiny relative to disk sizes today).

*The* biggest headache is HTTP support.  Even the simplest modern HTTP server is so complex you can never be reasonably sure it's secure (though, granted, it's simpler than a browser!)  You'd want to stay simple and primitive.

Probably the biggest threat to such a device is a rogue update that installs malware.  You can try to mitigate that risk by requiring that all updates be signed by multiple independent parties who vet the patch, but there are difficult tradeoffs:  Too few checkers, and a rogue patch can get through; too many, and if a severe problem develops, you can't get a patch out quickly.

I think the goal to aim for is no patches!  Keep the device and its interfaces simple enough that you can get a decent formal proof of correctness, along with a ton of careful review and testing (per Don Knuth's comment somewhere to "Be careful of the following code, I've only proved it correct, not tested it") and then *leave it alone*.  If you don't think you can do without patches for the whole thing, maybe you can have a non-patched security kernel, with patches only to portions that cannot break your security guarantees.  (Yes, this is also a hard problem.)

An important element of a secure design is some sort of obliviousness.  A mail server doesn't, on its own, need to look at much in a message:  For the most part, it just stores and forwards bags of bytes.  Where mail servers have gotten into trouble is when they've tried to provide additional services - e.g., virus scanners, which then try to look inside of complex formats like zip files.  This is exactly the kind of thing you want to avoid - another part of the "mission creep" that we tend to see in anything that runs on a general-purpose computer. (The CPU is idle most of the time, why not give it some more work to do?)  That's 20th century thinking:  The computer is expensive, keep it busy.  Twenty first century thinking should be:  The computer is cheap - leave it alone to do its job securely.

Realistically, it will be impossible to get little appliances like this patched on a regular basis - how many people patch their WiFi routers today? - so better to design on the assumption there won't be any patches.

                                                        -- Jerry


> I
> don't think we can run anything like that directly on a phone, it would
> drain the battery way too quickly.
> -- Christian Huitema
> 
> 
> 
> 
> 
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography



More information about the cryptography mailing list