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 

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@metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography

The cryptography mailing list

Reply via email to