[00:00.000 --> 00:01.280]  To how we communicate.
[00:04.130 --> 00:09.690]  Our next speaker, our next speakers are here because they are here to fix some of the problems with email.
[00:10.890 --> 00:16.550]  And, well, I think that, I can't quite see if everything's ready to go.
[00:46.970 --> 00:47.730]  All right.
[00:51.140 --> 00:56.720]  Our next two speakers are here to talk about the dark mail project to fix some of the fundamental problems with email.
[00:59.620 --> 01:06.300]  Speaking later will be Steven Watt, but first I'd like everyone to welcome one of the people that had the audacity to defy some of the will of the federal government.
[01:07.760 --> 01:08.500]  Ladar Levison.
[01:19.990 --> 01:23.070]  It's always hard to get technology working at a technology conference.
[01:26.350 --> 01:28.990]  I wanted a wireless mic because I like to walk around.
[01:29.170 --> 01:32.810]  I'm not used to being up here on a stage in front of a bunch of people.
[01:34.830 --> 01:37.090]  I'm used to sitting out there with you guys.
[01:37.910 --> 01:44.010]  It's actually kind of a shame that RMS isn't here because I know if he was, he'd be happy to hop up and take my place.
[01:47.420 --> 01:53.500]  Since I have an untainted audience, I thought I would start with a couple of survey questions.
[01:54.640 --> 02:05.340]  By a show of hands, how many people think SMTP is broken from a security standpoint and can't be fixed?
[02:10.070 --> 02:10.870]  Okay.
[02:12.270 --> 02:19.650]  How many people think the word X.509 certificate is a dirty phrase?
[02:22.990 --> 02:23.790]  Okay.
[02:25.610 --> 02:34.150]  How many people think their emails are being read as they travel across the Internet by somebody other than the intended recipient?
[02:35.330 --> 02:35.930]  All right.
[02:36.090 --> 02:36.850]  Keep your hands up.
[02:37.870 --> 02:40.050]  How many people think that's a problem?
[02:43.360 --> 02:44.620]  Keep your hands up.
[02:45.920 --> 02:48.140]  How many people are doing something about it?
[02:51.890 --> 02:52.830]  A lot fewer hands.
[02:56.050 --> 03:01.730]  Some of you may know I found myself with a lot of extra free time on my hands last fall.
[03:04.750 --> 03:07.490]  So I thought I would try and do something about it.
[03:09.590 --> 03:16.570]  And my proposal is what I'm here today to present so that you can afterwards make fun of me.
[03:21.350 --> 03:22.850]  I call it dark mail.
[03:23.890 --> 03:32.930]  Because during a conversation with John Callas, when we were talking about what the NSA was doing, he said, screw those expletives.
[03:33.170 --> 03:35.270]  We'll just make all the messages go dark.
[03:36.350 --> 03:37.290]  I was like, yeah.
[03:38.470 --> 03:39.270]  Screw them.
[03:40.330 --> 03:41.670]  How are we going to do this?
[03:46.640 --> 03:49.640]  So the project has really evolved.
[03:51.580 --> 03:54.320]  We started with a number of different approaches.
[03:55.760 --> 03:59.200]  And we keep coming back to PGP.
[04:00.380 --> 04:04.080]  Maybe that's because Phil and John created it.
[04:04.260 --> 04:08.800]  And since I talk to them a lot, they have somewhat of an influence on my thinking.
[04:11.080 --> 04:16.560]  But it really came down to how do we fix the problems with PGP.
[04:17.620 --> 04:24.160]  Now, of course, what we define as the problems is pretty important, right?
[04:25.900 --> 04:29.940]  In security, everybody defines the problem differently.
[04:34.400 --> 04:42.080]  For some people, if your password gets compromised and they can read your messages, that's a problem.
[04:44.580 --> 04:48.380]  For others, it's like, they compromised your password, dude.
[04:48.540 --> 04:49.180]  What'd you expect?
[04:51.780 --> 04:59.820]  So, I'm going to start by talking about what problems I'm trying to solve.
[05:01.460 --> 05:07.760]  Because I think they're a little bit different than some of the other proposals out there.
[05:13.090 --> 05:17.750]  The first big problem is key management.
[05:19.690 --> 05:32.090]  That is, the generation of keys, the rotation of your key, the process of securely finding the key for somebody else, and then validating that that result is correct.
[05:34.750 --> 05:46.710]  How do you make that process happen automagically in the background so that grandma doesn't need to know anything about cryptography, but yet her messages are completely encrypted end to end?
[05:49.950 --> 06:21.970]  My goal is to build a platform, a system, a set of protocols that, in theory, if implemented properly, would allow you to take a client as simplistic as Apple Mail, which has the absolute fewest number of clickable buttons, not change a single thing, and allow it to do end-to-end encryption on your device with everyone else out in the world.
[06:24.250 --> 06:34.190]  But I'm smart enough to know that there isn't one true and correct way that everybody must use.
[06:35.310 --> 06:37.970]  Some people want a little more flexibility.
[06:39.390 --> 06:53.310]  So I may not state it later in my talk, but if you really like the way PGP works, and you really enjoy doing manual fingerprint comparisons over the phone, you still can.
[06:57.030 --> 07:09.710]  My goal is to get the rest of the world to a much safer place without having to know or learn anything new.
[07:12.620 --> 07:17.720]  My second major goal, and this is a new one,
[07:21.080 --> 07:23.140]  is metadata minimization.
[07:25.740 --> 07:28.900]  Turns out who you're talking to is pretty important.
[07:30.220 --> 07:33.140]  We always thought we had the freedom to associate.
[07:35.550 --> 07:47.140]  Turns out that simply emailing somebody is enough evidence for a judge to issue a search warrant for the contents of your inbox.
[07:50.870 --> 07:56.090]  I think we lost the freedom of association at some point along the way, and we didn't realize it.
[07:57.330 --> 07:59.690]  So the goal is to get that back.
[08:02.250 --> 08:20.810]  It's not to create Tor or recreate Tor, but merely limit the amount of information about a message that the server can access to the absolute minimum amount of information that it needs in order to make mail functionality work.
[08:22.970 --> 08:24.910]  In short, we encrypt the headers.
[08:26.450 --> 08:44.450]  And we encrypt the header, and we separate out the envelope information from the rest of the headers, and encrypt that so that each hop along the way only has access to the information it absolutely needs in order to get the message to the next hop.
[08:46.050 --> 08:51.770]  Some people might recognize that idea from another major project in the security space.
[08:53.410 --> 08:55.810]  It's the idea that your mail server is an onion.
[08:58.570 --> 08:59.850]  It's not an onion router.
[09:00.250 --> 09:00.890]  It's not Tor.
[09:03.370 --> 09:05.010]  But the idea holds true.
[09:06.410 --> 09:09.130]  That's why I call it minimization and not protection.
[09:09.370 --> 09:16.050]  Because if I called it protection, everybody up here would jump up on top of me and say, but we can see the DNS queries going back and forth.
[09:17.590 --> 09:23.610]  We know where the packets are flowing because our attacker can see the entire Internet and record everything all at once.
[09:24.910 --> 09:25.530]  Well, yeah.
[09:27.570 --> 09:29.690]  But they won't know who you're talking to.
[09:30.870 --> 09:34.250]  They'll just know where your packets are flowing and what domains you looked up.
[09:34.250 --> 09:36.650]  That's minimization.
[09:41.680 --> 09:55.960]  And three, to engineer a system that is resistant to advanced and sophisticated threats with virtually unlimited resources.
[09:56.340 --> 10:03.720]  I say resistant because given enough time, I'm sure they will figure out some way to break somebody's email.
[10:06.080 --> 10:09.920]  But ultimately, the rest of us should be safe.
[10:10.760 --> 10:22.080]  My goal, my high-level goal, is that if everybody switched to dark mail tomorrow, or in six months when it's actually available,
[10:25.330 --> 10:29.690]  that mass surveillance would become technologically impossible.
[10:32.960 --> 10:38.640]  Now, I'm going to talk a little bit later about the three different modes of operation.
[10:40.140 --> 10:49.140]  I only really consider two of them secure because they do the encryption on the user's device.
[10:50.080 --> 10:59.600]  But the goal in those modes of operation is to make the security of your messages come down to two factors.
[11:02.500 --> 11:09.220]  The strength of your password and the strength of your endpoint defenses.
[11:12.160 --> 11:19.040]  Now, I think, or at least hopefully, most people in this room will appreciate the importance of a strong password.
[11:20.080 --> 11:23.080]  For the rest of the world, that's still kind of a learning curve.
[11:25.700 --> 11:39.180]  I still love hearing all of the horror stories about Bitcoin people who had millions of dollars in their wallet and can't remember their password or threw out the hard drive by accident without a backup.
[11:42.330 --> 11:44.070]  So there will be a learning curve.
[11:44.790 --> 11:48.250]  If you forget your password, you lose access to all your messages.
[11:54.290 --> 12:01.050]  In terms of endpoint defenses, I've got some ideas on how to fix that.
[12:03.030 --> 12:12.690]  But because I don't have a mandate from Congress and a $600 million budget like, oh, healthcare.gov, I kind of had to restrict my scope.
[12:15.490 --> 12:17.630]  I'm leaving that problem up to you guys.
[12:19.550 --> 12:20.770]  But it is a problem.
[12:23.010 --> 12:33.950]  There aren't very many devices out there, at least consumer devices, that we can truly call secure.
[12:38.130 --> 12:48.290]  Now, I had hoped to work a little more closely with Silent Circle and Phil and John, but they've actually been really busy lately trying to solve that very problem.
[12:49.010 --> 12:53.690]  Trying to create an Android phone that is secure.
[12:54.590 --> 13:02.130]  That will allow you to run Angry Birds without having to worry about it turning on your microphone or your camera and spying on you in the background.
[13:03.710 --> 13:06.470]  Turns out it's a really tricky problem.
[13:14.490 --> 13:15.870]  So those are my goals.
[13:18.290 --> 13:22.450]  Now I step into dangerous territory and tell you how I think we should solve them.
[13:26.760 --> 13:37.120]  The first principle I want to explain about dark mail is that it was designed intentionally to be flexible.
[13:38.380 --> 13:43.120]  We all deploy email differently on our networks.
[13:43.120 --> 13:44.840]  We all use it differently.
[13:47.100 --> 13:50.860]  We all have different threats that we worry about.
[13:55.240 --> 14:11.560]  And in order to allow for that, we tried to design a system that would allow you to use it differently based on your own perceived threat model.
[14:13.920 --> 14:16.120]  We call that...
[14:16.120 --> 14:20.440]  So I guess I should give a little anecdotal story here.
[14:20.840 --> 14:27.460]  I've been working with Dave Crocker on the architecture and protocol design documents.
[14:28.040 --> 14:40.560]  He's extremely helpful at taking my micro level concept and expressing it using really big words in a way that standard bodies like.
[14:40.560 --> 14:43.520]  That's very abstract and hard to understand.
[14:45.360 --> 14:49.220]  But we've had long and very interesting discussions about nomenclature.
[14:52.200 --> 15:07.430]  And we decided that because what I'm about to describe truly governs where the private key for an account is stored, it governs how a client operates.
[15:07.430 --> 15:10.470]  So we're calling it the client mode.
[15:12.170 --> 15:19.630]  Some of you may prefer to call it protocol mode or trust mode or anything but client mode.
[15:20.170 --> 15:25.610]  But at its heart, it governs how private keys are handled.
[15:27.210 --> 15:36.930]  And we decided we would create three predefined modes to cover three different types of users.
[15:38.730 --> 15:40.630]  And we named them appropriately.
[15:41.770 --> 15:44.150]  Trustful, cautious, and paranoid.
[15:47.440 --> 15:51.340]  So I said earlier I only truly consider two of those secure.
[15:53.100 --> 15:57.660]  And I'm going to spend most of my time talking about cautious and paranoid.
[15:59.720 --> 16:09.380]  Trustful mode implies that you trust the server to handle the encryption on your own behalf.
[16:11.200 --> 16:34.780]  Now in reality, what I'm saying is no matter what I recommend, there will be people out there either because they have too much invested in their current infrastructure to upgrade it, or some sort of regulatory requirement like Sarbanes-Oxley that requires archiving and others to be able to read your email within an organization,
[16:36.700 --> 16:56.960]  that will say, hey, we will just do the encryption on the server and let people continue to use SMTP and IMAP inside the organization, but send the messages out over the Internet encrypted, at least when talking to a darkmail domain.
[17:00.920 --> 17:02.840]  Think of it as a proxy.
[17:03.580 --> 17:10.100]  Not a SOCKS proxy, but like a banker proxy or a lawyer proxy.
[17:12.540 --> 17:16.900]  In standard speak, it's the user privacy agent.
[17:21.200 --> 17:28.380]  It does all of the functions that ideally would be handled by the client.
[17:31.830 --> 17:49.510]  So let's... well, I guess I should interject right there and give a little prelude to my partner in crime and say that in many ways, trustful mode could be implemented much like the way Lavabit worked before I shut it down.
[17:51.050 --> 17:59.610]  Where the private key is encrypted with the password and gets decrypted when you log in and allows you to operate on the account but still stores everything securely.
[18:00.450 --> 18:02.350]  Of course, it doesn't have to do that.
[18:02.590 --> 18:04.170]  It's kind of up to the implementation.
[18:05.790 --> 18:14.270]  But that ultimately the encryption is done on the server and we rely on SSL to create a secure bridge between it and the user.
[18:16.350 --> 18:22.470]  So technically speaking, trustful mode is still secure if you trust SSL to be secure.
[18:24.970 --> 18:27.450]  I used to trust SSL to be secure.
[18:29.410 --> 18:32.670]  But then again, I used to think that I could hold on to my own private key.
[18:32.670 --> 18:34.050]  It's private, right?
[18:39.190 --> 18:41.850]  I could get into a long talk about SSL.
[18:44.410 --> 18:45.790]  Technically and legally.
[18:46.070 --> 19:02.930]  But let me summarize by saying that if all that comes out of the Snowden disclosures for email is that we start using TLS for SMTP between servers, we've lost.
[19:06.370 --> 19:11.370]  There are too many ways to game that system, especially in the mail world today.
[19:12.850 --> 19:14.490]  Facebook did a great study.
[19:15.470 --> 19:21.910]  They found that 90% of the MX records out there now support TLS.
[19:23.550 --> 19:29.010]  But what they also found is that only about 40% of them would pass strict validation.
[19:29.610 --> 19:31.670]  The certificate isn't expired.
[19:31.970 --> 19:33.390]  It has the correct common name.
[19:33.810 --> 19:37.030]  It's signed by a valid CA and hasn't been revoked.
[19:39.250 --> 19:46.590]  They also found that there's no way to know when they should be using SSL and when they shouldn't.
[19:46.590 --> 19:51.850]  So if somebody intercepted the connection, they could just tell you they don't support SSL and the message would go through anyways.
[19:57.950 --> 19:58.850]  I'll stop there.
[20:03.330 --> 20:05.530]  Cautious mode and paranoid mode.
[20:05.530 --> 20:05.670]  Cautious mode.
[20:07.430 --> 20:18.870]  Like I said, the goal is to have the security come down to the strength of your password and the security of your end point devices.
[20:21.170 --> 20:28.770]  If they can get malware onto your computer, they can steal pretty much everything you type.
[20:30.210 --> 20:33.990]  It doesn't matter if they can actually access the messages stored on disk.
[20:34.310 --> 20:39.890]  They can just record you typing them or take screenshots when you're reading them.
[20:41.070 --> 20:51.430]  Or if you happen to be a South American president, swap out your VGA cable with a microwave transmitter and watch everything that shows up on your monitor while giving you cancer for free.
[20:52.930 --> 20:53.810]  It's a feature.
[21:00.080 --> 21:22.340]  The primary difference between cautious and paranoid mode is that in cautious mode, your private keys are encrypted locally with your password and then stored on the server so that if you log in from a different client, all of your information is still there.
[21:23.480 --> 21:28.380]  Remember, my goal isn't to change the way you use e-mail.
[21:28.780 --> 21:31.660]  I want you to be able to keep using it the way you use today.
[21:35.220 --> 21:40.300]  I just realized that most people in this room probably don't use e-mail the way most others do.
[21:41.100 --> 21:48.660]  So let me clarify by saying that I want you to be able to keep using e-mail securely the way most people use e-mail.
[21:49.720 --> 21:51.920]  Which is you access it from your phone.
[21:53.320 --> 21:54.400]  A web browser.
[21:56.120 --> 22:01.020]  Maybe you have a thick client on your laptop or your home computer and your work computer.
[22:01.820 --> 22:04.860]  And you like having all of those messages stay in sync.
[22:05.720 --> 22:08.480]  And you like to be able to access your old messages.
[22:09.140 --> 22:11.520]  See which ones you've read and which ones you haven't.
[22:12.780 --> 22:18.280]  In other words, all of that functionality that was state of the art in 1996 when they came out with IMAP.
[22:19.240 --> 22:21.540]  And then took everyone five years to implement.
[22:24.700 --> 22:25.740]  I can...
[22:27.460 --> 22:38.520]  I got to meet the lead programmer for DoveCot a few weeks back and we got to share horror stories about implementing IMAP as a protocol.
[22:39.160 --> 22:48.200]  It ended up taking me three times as long to implement IMAP as it did to implement SMTP and POP combined.
[22:49.460 --> 22:50.440]  Fun times.
[22:51.360 --> 22:54.220]  I miss the days when I was just a lonely programmer.
[22:56.540 --> 22:59.280]  Didn't have to stand up in front of audiences like this.
[23:06.270 --> 23:22.670]  Paranoid mode is really a recognition of the fact that if I said as a protocol, we were going to encrypt your private keys and put them on a server, I know somebody out there would create an implementation that just takes a string of zeros, encrypts it,
[23:22.850 --> 23:25.430]  uploads it to the server and says this is my private key.
[23:26.590 --> 23:31.150]  So I said why not formalize that behavior and just call it paranoid mode.
[23:32.610 --> 23:35.270]  You get to synchronize the data between your devices.
[23:41.540 --> 23:49.340]  But because I've integrated this into the protocol, it can all happen under the covers.
[23:50.920 --> 24:07.020]  Your client generates a key for you, rotates that key periodically, pushes it to the server, the public key portion I should say, which then signs it and publishes it on your behalf.
[24:08.280 --> 24:21.080]  And because I'm told the word certificate can never be used in front of a standards body without being laughed at, we're calling the end result a signet.
[24:23.040 --> 24:23.880]  Ta-da!
[24:25.640 --> 24:27.880]  So this is what jobs must feel like.
[24:31.730 --> 24:39.730]  Bright lights, big audience, revealing something that sounds completely ridiculous and new to the entire world.
[24:40.090 --> 24:46.410]  Yes, we no longer call them public keys, we no longer call them certificates, we call them signets.
[24:47.890 --> 24:52.710]  I have stickers for anybody who knows the origin of that word without using Wikipedia.
[24:56.980 --> 24:59.340]  But that's our basic trust model.
[25:03.490 --> 25:13.130]  The user generates the key, has it signed by the organization, which then becomes the authoritative source for that key.
[25:14.110 --> 25:24.150]  The organizational key available also on the same server, which by the way is part of the mail protocol.
[25:25.310 --> 25:30.750]  We're calling it DMTP because everybody knows stupid mail protocol.
[25:31.110 --> 25:33.950]  Transport protocol is broken beyond repair.
[25:37.430 --> 25:41.010]  Is what you use to transport messages and look up keys.
[25:42.290 --> 25:46.670]  And then the organizational key is pinned to the DNS system.
[25:47.650 --> 25:50.710]  Now I know about all the security problems with DNS.
[25:53.210 --> 25:56.630]  Again, I don't have the same budget as healthcare.gov.
[25:57.150 --> 25:58.970]  So I have to kind of limit my scope.
[26:01.150 --> 26:08.830]  But the bottom line is that without DNS, we just don't really have email as we think about it today.
[26:10.810 --> 26:12.210]  So I'm kind of stuck with it.
[26:14.370 --> 26:17.170]  But I would recommend the use of DNSSEC.
[26:17.410 --> 26:24.350]  Turns out less than half a percent of the .com domains actually sign their DNS zones.
[26:25.290 --> 26:28.370]  I know lavabit.com isn't signing its own right now.
[26:28.570 --> 26:30.750]  But then again, who's actually using that domain anymore?
[26:35.460 --> 26:38.500]  I'll let Steven talk about that in a few minutes.
[26:38.800 --> 26:40.760]  But it's actually kind of a problem.
[26:42.980 --> 26:54.020]  The other big problem with DNS is that because everything is sent out via unencrypted UDP packets, somebody sitting on your upstream link can see which domains you're looking up.
[26:55.480 --> 27:07.660]  So yes, they may not know that you are talking to Bob at madeupdomain.com, but they do know that you did a DNS query for madeupdomain.com.
[27:08.900 --> 27:14.880]  And if madeupdomain.com is really apple bomb.net, they probably know who you're talking to.
[27:16.220 --> 27:18.520]  Again, metadata minimization.
[27:22.120 --> 27:24.420]  We reduce it to the org level.
[27:25.380 --> 27:30.520]  The bigger the domain, the more traffic going through the servers, the harder it is to find out anything useful.
[27:31.520 --> 27:48.220]  And because the servers don't know who you're talking to beyond a domain level, they can no longer be forced to turn over log files which tell an attacker exactly who you've been communicating with.
[27:48.220 --> 27:52.400]  All they know is we handed off a message to madeupdomain.com.
[27:54.660 --> 28:03.220]  They have to go to madeupdomain.com and if madeupdomain.com has a log file that allows them to link it back, maybe they can figure out who they delivered it to.
[28:05.220 --> 28:06.380]  It's like an onion, right?
[28:07.360 --> 28:08.940]  Four points along the path.
[28:10.060 --> 28:12.920]  The two points at either end are the users.
[28:13.420 --> 28:14.660]  They can see everything.
[28:15.420 --> 28:19.120]  The two points in the middle are the origin domain and the destination domain.
[28:19.340 --> 28:21.360]  And they can only see the point on either side of them.
[28:22.210 --> 28:26.710]  The origin can see who sent the message and what domain it was delivered to.
[28:26.960 --> 28:33.940]  And the destination domain can see the origin domain and who they need to deliver the message to.
[28:36.160 --> 28:42.400]  And, of course, the first two hops along the way add signatures so that everything can be stamped and validated.
[28:44.540 --> 28:47.240]  I kind of like what PGP gives us, right?
[28:47.540 --> 28:50.180]  Message confidentiality and non-repudiation.
[28:51.660 --> 28:56.380]  I'm just trying to add some extra stuff for no added cost.
[28:59.560 --> 29:29.640]  I really do mean that in the sense that as somebody who's kind of lived the entire life cycle of programmer, engineer, designer, support person, accountant, CEO, whatever that means, troubleshooter, database admin, et cetera, I know what it's like to get some fancy new tool and have to spend the next three weeks of my life learning how it works so I understand the security implications of it.
[29:32.430 --> 29:56.090]  So while D-mail will make implementations at the client and server level more complicated, our goal is that if you're using a D-mail compatible server or client, as an administrator, the only thing you need to do differently to get email up and running is to create that validation record in your DNS system.
[29:57.310 --> 30:04.250]  And if you really use DNS a lot today, you've probably done that already with something like DKM or SPF or sender ID.
[30:05.230 --> 30:06.010]  Just joking.
[30:06.170 --> 30:07.330]  Nobody ever used sender ID.
[30:08.670 --> 30:09.790]  Or DMART.
[30:11.230 --> 30:13.750]  I don't know how many mail heads I have in the audience.
[30:16.630 --> 30:19.590]  So you probably know what all those acronyms really mean.
[30:22.350 --> 30:25.050]  I have a joke there, but it's not politically correct.
[30:29.380 --> 30:33.660]  So you publish that validation record and then everything happens automagically for you.
[30:37.360 --> 30:45.020]  Unfortunately, I can't explain in a very detailed way how that all happens without either A putting you to sleep or B having it take three days.
[30:46.040 --> 30:48.020]  So I'm trying to keep it at a high level.
[30:49.600 --> 30:50.580]  But I'm trying to keep it at a high level.
[30:50.580 --> 30:56.260]  But I'm also trying to back up what I'm saying by working on a reference implementation.
[31:03.110 --> 31:23.530]  There is one thing that I want to drill into everybody's head, which is the fact that in the D-mail world, in order for a result to be trusted, there needs to be a primary lookup source and a pre-authenticated, secondary lookup source.
[31:23.550 --> 31:25.110]  secondary source for validation.
[31:28.770 --> 31:36.470]  It's one of those great terms where everybody in the room probably has a different interpretation of what it actually means.
[31:38.970 --> 31:53.950]  But DNSSEC or DNS with DNSSEC could be considered a pre-authenticated secondary source because the DNSSEC root keys ship with the resolver.
[31:53.950 --> 31:54.030]  server.
[31:55.910 --> 31:59.350]  Certificate authorities could be considered a pre-authenticated source.
[32:02.270 --> 32:03.850]  Sorry, somebody was waving at me.
[32:03.990 --> 32:04.730]  I thought it was time.
[32:07.970 --> 32:16.210]  And the validation record could be a DNS entry that has a hash or a copy of the public key.
[32:17.890 --> 32:23.110]  So that you can validate the complete signet from where you looked it up in the first place.
[32:24.070 --> 32:25.550]  Presumably the mail server.
[32:25.830 --> 32:28.030]  Presumably the mail server of the domain that you're trying to contact.
[32:36.340 --> 32:43.180]  I guess I'm going to talk here about another component that unfortunately won't be available right away.
[32:45.080 --> 32:50.200]  I guess what we're calling a global ledger.
[32:50.660 --> 33:05.780]  And it's an external distributed piece of the architecture which you can syndicate your key in public key information to and which could also be considered a pre-authenticated source.
[33:07.860 --> 33:27.590]  In other words, if you're not using DNSSEC, you're going to have to figure out another way of allowing people to validate your org signets and your user keys.
[33:28.970 --> 33:36.650]  And I'm going to save the exact rules for how that process works to when I've actually written them down.
[33:36.810 --> 33:36.890]  No.
[33:39.770 --> 33:41.850]  To another talk when I have more time.
[33:43.210 --> 33:51.610]  But it's the idea that if the validation record isn't signed by DNSSEC, then it still needs to exist.
[33:51.610 --> 34:03.430]  But we fall back to the TLS certificate and make sure it's signed by a CA in our local repository that we trust.
[34:03.590 --> 34:10.210]  That it becomes a pre-authenticated source that we actually got the result we think we got from the person we think we got it from.
[34:11.810 --> 34:16.710]  And what it does from a security perspective is quite simple.
[34:18.430 --> 34:27.930]  It means that if somebody has complete control over your upstream Internet connection, they actually need to compromise a private key in order to trick the system.
[34:29.310 --> 34:35.310]  Now, they could compromise one of several private keys along the way, but they have to compromise at least one of them.
[34:36.450 --> 34:45.830]  If we don't have a pre-authenticated source, well, then they can just trap you in what Julia calls the hall of mirrors.
[34:46.790 --> 34:48.590]  You know, like at a circus.
[34:50.130 --> 34:53.130]  And just basically generate a fake Internet.
[34:54.450 --> 34:56.830]  And results for everything that you might look up.
[35:00.500 --> 35:01.960]  But that's my idea.
[35:02.860 --> 35:04.020]  Had it for a long time.
[35:05.680 --> 35:10.000]  Added the metadata protection and the resistance to advance persistent threats.
[35:11.700 --> 35:13.920]  Because of what happened in the last year.
[35:15.500 --> 35:28.560]  And the idea of, hey, who knows better whether something is actually the public key of a particular email account than the email server that has authenticated the user.
[35:31.260 --> 35:35.620]  Of course, every organization could have their own way of handling it.
[35:41.580 --> 35:42.860]  Corporate America.
[35:43.300 --> 35:44.320]  Gotta love it.
[35:45.780 --> 35:58.100]  But the idea is, once you have this Cygnet in your Cygnet ring, it becomes a new source for validating rotated keys.
[35:58.100 --> 36:00.800]  Because we've created another new concept.
[36:01.720 --> 36:04.660]  Something I call the chain of custody.
[36:06.660 --> 36:11.320]  I need a very dramatic musical score to go with that.
[36:11.620 --> 36:13.540]  Because it's incredibly important.
[36:13.540 --> 36:19.720]  It's the idea that you can rotate your public key as often as you want.
[36:20.180 --> 36:21.820]  Within some limit.
[36:22.100 --> 36:24.660]  Like, say, 1776 minutes.
[36:26.500 --> 36:35.100]  And that you simply sign the new Cygnet with your previous private key.
[36:36.180 --> 36:52.060]  That way, somebody who has a previous lookup cast locally can trace the chain of custody from their previous result to what they just found and ensure one thing.
[36:53.600 --> 36:56.080]  And I'm going to be very precise with my language.
[36:56.800 --> 37:01.060]  Because I know others will jump up on top of this and say...
[37:01.620 --> 37:04.580]  Or others may think that it does something more than this.
[37:04.880 --> 37:10.300]  But what it helps to ensure is that whoever...
[37:11.460 --> 37:19.960]  It helps to ensure that you're talking to the person who controlled the account the last time you talked to the person...
[37:19.960 --> 37:22.120]  Or to that particular email address.
[37:24.420 --> 37:29.720]  In other words, that your service provider isn't doing a man-in-the-middle attack on that particular account.
[37:29.920 --> 37:32.460]  Remember, I'm talking about cautious and paranoid mode here.
[37:33.360 --> 37:34.880]  Trustful mode, that goes out the window.
[37:35.000 --> 37:36.860]  You still need to trust your service provider.
[37:44.010 --> 37:44.850]  It's important.
[37:46.530 --> 37:50.130]  Because if there's a break in the chain of custody...
[37:50.830 --> 37:57.030]  We give you one of those ever-so-easy-to-understand modal dialogues that says something like...
[37:57.550 --> 37:59.830]  There has been a break in the chain of custody.
[38:00.010 --> 38:01.850]  And of course you know what that means, so I'll stop there.
[38:02.210 --> 38:02.310]  No.
[38:03.150 --> 38:05.930]  It says there has been a break in the chain of custody.
[38:05.930 --> 38:09.010]  Which means we can no longer guarantee...
[38:09.950 --> 38:13.490]  That the same person...
[38:15.590 --> 38:16.270]  Controls...
[38:16.270 --> 38:18.390]  The email address...
[38:18.390 --> 38:21.050]  X at Y dot com...
[38:21.730 --> 38:23.490]  That you spoke to last time.
[38:25.050 --> 38:27.210]  Now this could be something innocent.
[38:27.650 --> 38:29.050]  Like a password reset.
[38:29.590 --> 38:30.710]  Or something malicious.
[38:31.050 --> 38:32.070]  Like a man-in-the-middle attack.
[38:33.010 --> 38:36.790]  Because every regular old user knows what a man-in-the-middle attack is, right?
[38:38.070 --> 38:38.770]  I'm just kidding.
[38:38.990 --> 38:41.870]  A copywriter will actually figure out the real text.
[38:43.810 --> 38:45.110]  But that's the idea.
[38:48.960 --> 38:51.500]  Some would call that trust on first use.
[38:54.090 --> 38:56.250]  And then chaining the trust forward.
[38:56.960 --> 38:59.570]  But I think it's a little more complicated than that.
[38:59.570 --> 39:04.230]  Because we don't necessarily automatically trust on first use.
[39:04.880 --> 39:11.440]  Like say for example, grabbing a random key off of a public key server and just assuming it's correct.
[39:11.860 --> 39:13.170]  Until proven otherwise.
[39:13.730 --> 39:15.750]  We actually do validation checks.
[39:18.320 --> 39:20.360]  But the way it should work...
[39:21.220 --> 39:23.460]  Is the way DNS works today.
[39:24.800 --> 39:30.320]  Hey, I want to find out where the web server is for some random domain.
[39:31.270 --> 39:37.860]  I'm going to contact the authoritative DNS server for random domain and find out what IP address it resolves to.
[39:39.300 --> 39:56.340]  Well, what we're trying to create is a way of creating a resolver to look up the public key, or more accurately, the signet for random email addresses.
[40:00.330 --> 40:02.930]  That's what email is.
[40:03.250 --> 40:14.150]  It's an asynchronous method of communication that allows you to send a message from anyone to anyone without them ever having talked to each other in the past and without both of them being online at the same time.
[40:14.690 --> 40:15.870]  It's a mouthful, right?
[40:17.550 --> 40:20.410]  If it doesn't allow that, it's not email.
[40:24.520 --> 40:31.720]  Now, there's some great other projects out there that allow you to communicate that have different security properties.
[40:32.660 --> 40:34.680]  But they don't function like email.
[40:34.860 --> 40:38.600]  And if they don't function like email, they're not going to replace email.
[40:39.060 --> 40:47.900]  And if they don't replace email, well, odds are people will keep still using email.
[40:50.640 --> 40:52.220]  At least that's my take on it.
[40:52.380 --> 40:54.800]  It's kind of why I got into the email business in the first place.
[40:56.420 --> 41:01.180]  I was like, wow, I have six billion people on the planet and they all need an account.
[41:02.040 --> 41:06.520]  I'm guaranteed a customer base forever.
[41:07.780 --> 41:10.400]  Because they're probably going to need more than one account.
[41:11.540 --> 41:15.040]  And we're probably never going to be able to stop using email.
[41:17.740 --> 41:20.760]  But being able to secure it is incredibly important.
[41:20.760 --> 41:25.580]  Because email has become the heart of your online identity.
[41:28.140 --> 41:33.080]  For the Americans in the room, it's like your digital equivalent of your social security number.
[41:35.200 --> 41:42.760]  If you can break open somebody's email, you can take over their online life.
[41:43.620 --> 41:48.820]  It's kind of why I always took the security of my email system so seriously.
[41:50.040 --> 41:52.520]  I was protecting people's identities.
[42:01.820 --> 42:03.840]  Now, I have a lot more to talk about.
[42:05.600 --> 42:07.420]  But no time to talk about it.
[42:08.720 --> 42:18.580]  So, at this point, what I'm going to do is turn over the microphone to the guy who gets to do the fun part.
[42:20.160 --> 42:21.360]  Actually, write the code.
[42:22.740 --> 42:29.120]  And he's going to spend a few minutes talking about our general strategy for doing that.
[42:30.760 --> 42:37.820]  Maybe a few things thrown in about what we've been doing the last few months with our release of Magma Classic.
[42:38.560 --> 42:39.880]  Yeah, I kind of have a lava theme.
[42:41.520 --> 42:42.080]  Steven?
[42:55.910 --> 42:56.630]  All right.
[42:57.050 --> 43:02.550]  So, as Ladar mentioned, I'm the person responsible for actually turning his ideas into code that compiles.
[43:03.030 --> 43:05.630]  As he said, he used to one day be a lonely programmer.
[43:07.250 --> 43:07.610]  Right.
[43:08.070 --> 43:12.310]  But these days, as Wire described him earlier today, he is now an Internet icon.
[43:12.610 --> 43:14.410]  So, there's not as much time for that.
[43:14.630 --> 43:18.810]  I just wanted to go over some of the technical details of where the project is right now.
[43:19.070 --> 43:20.910]  First, to start off with a little bit of nomenclature.
[43:20.910 --> 43:24.310]  So, a lot of people don't really know this.
[43:24.490 --> 43:31.730]  But Ladar actually spent almost 10 years working on this custom rig that powered lavabit.com.
[43:32.430 --> 43:36.850]  And that is what is now referred to as Magma Classic.
[43:37.170 --> 43:41.690]  Because it supports a classic legacy mail protocols that everybody is familiar with.
[43:41.930 --> 43:43.930]  SMTP, IMAP, POP3.
[43:44.130 --> 43:47.930]  And what we're cobbling onto that is actually called Magma Dark.
[43:47.930 --> 43:51.810]  So, Magma Dark might refer to the D-mail extensions.
[43:52.270 --> 43:57.090]  Or it could refer to the entire bundle with the D-mail extensions added on to Magma Classic.
[43:58.210 --> 44:01.630]  So, Magma is a monolithic architecture.
[44:01.930 --> 44:06.670]  So, you basically have everything running together, multi-threaded in one process space.
[44:06.790 --> 44:11.070]  So, what normally would be separate daemons for POP3 and IMAP.
[44:11.230 --> 44:12.470]  And then SMTP.
[44:12.850 --> 44:15.950]  And then perhaps a web server for running webmail.
[44:15.950 --> 44:18.890]  Is actually one unified server.
[44:19.190 --> 44:20.370]  All written in C.
[44:20.690 --> 44:24.410]  The web client that we're using for that is written in JavaScript, of course.
[44:24.710 --> 44:33.290]  And it uses JSON RPC as the communications method for sending data back and forth between the server for webmail clients.
[44:33.290 --> 44:48.290]  And so, for people that are paranoid about using some sort of third-party webmail server like squirrelmail and possibly opening themselves up to vulnerabilities in a scripting platform like PHP or Python.
[44:49.290 --> 44:52.030]  They can trust our lean mean C code.
[44:52.850 --> 44:59.310]  Magma is designed to scale and cluster using MySQL for data synchronization between server nodes.
[44:59.310 --> 45:02.350]  Just to give you a brief idea of the dependencies.
[45:02.870 --> 45:09.670]  On the SMTP portion, we have dependencies on CLAM AV, DSPAM, OpenDKIM, and OpenSPF.
[45:09.770 --> 45:19.650]  In general, we leverage memcached, Janssen for the JSON decoding, LibXML, OpenSSL, and MySQL.
[45:20.330 --> 45:22.850]  Something that's unique about the way that...
[45:22.850 --> 45:25.930]  I was going to say production had 098, so no heart bleed.
[45:25.930 --> 45:34.130]  Yeah, no heart bleed, but then again, it wasn't open to the world, so it's like a tree falling in a forest with nobody there to hear.
[45:36.010 --> 45:45.530]  One of the unique ways about the way that Magma is structured is we have this giant library called MagmaD.SO, which is probably a couple hundred megabytes before it's stripped.
[45:45.530 --> 45:58.690]  And the way that works is that all of our third-party libraries, library dependencies that I just mentioned, we actually compile them using special options and sometimes our own special custom patches.
[45:58.690 --> 46:02.170]  And then we link them together into this one massive library.
[46:02.330 --> 46:06.530]  And all external calls into these dependencies are resolved at run time.
[46:06.530 --> 46:15.590]  So there is basically no possibility of picking up some sort of system-wide version of a library that's insecure or slightly off.
[46:16.170 --> 46:22.690]  Uh, the resolver always make sure that if you're using something like OpenSSL, it's a version that we bundled in with the code.
[46:22.890 --> 46:25.730]  We minimize the use of things like libc calls.
[46:25.970 --> 46:34.450]  We use things like manage strings to ensure that string operations are done safely and efficiently inside C, which is always a challenge.
[46:34.450 --> 46:46.110]  Um, as far as memory management, we use memcached for our first tier of lookups, primarily for speed and scalability, but then we fall back to MySQL for stale data.
[46:46.910 --> 46:49.130]  Secure memory is also an interesting feature.
[46:49.410 --> 46:56.950]  Uh, we have an additional secure memory allocator slab that we use for sensitive data such as private keys or passwords.
[46:56.950 --> 47:04.630]  Uh, so essentially when memory regions on the slab are deallocated, they're wiped securely from memory.
[47:05.350 --> 47:12.150]  Also, if there is something like a core drum, dump triggered, they're, they're wiped before that core file is written to disk.
[47:12.390 --> 47:19.510]  Uh, and they're also memlocked into memory so that they never get paged out to something like a swap file.
[47:19.510 --> 47:43.210]  Uh, as far as the secure messaging system goes that he alluded to earlier that was running on Lavabit, each, if that's turned on for a user, then the user's password is used to derive a key, uh, that basically protects a private key that's part of a hybrid cryptosystem that is used to encrypt the user's messages on the file system.
[47:43.210 --> 47:55.210]  Uh, and for example, when they receive an incoming message using SMTP, that user's public key is looked up, and then that's used to encrypt the message so that only they can read it once they log in.
[47:55.890 --> 48:04.190]  As far as MySQL goes, the only information about each of those messages that we're storing is the numerical message ID and the numerical user ID.
[48:04.490 --> 48:10.730]  So everything like headers and that sort of metadata is actually stored encrypted inside the message body.
[48:12.470 --> 48:28.210]  My work on Magma Classic, apart from adding a few miscellaneous functions, of course, I had to make sure that certain hard-coded values specific to Lavabit were edited, uh, so that they would be more generally applicable to anybody that wanted to run the server.
[48:29.590 --> 48:35.830]  And our initial target is to have this running for CentOS 6.5 on a 64-bit architecture.
[48:36.090 --> 48:39.650]  Of course, anybody that follows up knows that CentOS 7 was recently released.
[48:39.650 --> 48:43.230]  So it's to be determined whether we're going to skip to that.
[48:43.710 --> 48:45.810]  Onto the D-mail reference implementation.
[48:46.230 --> 48:52.030]  The server portion, of course, includes the DMAP and the DMTP protocols.
[48:52.710 --> 48:55.490]  On the client side, we have two types of clients.
[48:55.650 --> 49:00.810]  We have the thin client, which is the JavaScript webmail client that we just discussed.
[49:00.910 --> 49:08.570]  And then we have the thick, more fully-featured and secure client, which is going to be a Thunderbird fork that we're going to call Volcano.
[49:09.150 --> 49:16.690]  Shared between the... Yeah, if you didn't get the whole magma, lava bit, volcano, it's, uh, geological references.
[49:18.170 --> 49:25.430]  Um... Shared between the client and server components, we're going to have parsers for the dark mail, mime-like headers.
[49:25.790 --> 49:31.970]  We're also going to have signet verification and handling routines, as well as the policy record resolver.
[49:32.570 --> 49:39.490]  Now, Ladar mentioned that DNSSEC is one of the ways that, for example, organizational signets might be validated.
[49:39.770 --> 49:44.210]  Uh, and we're probably going to have a little bit of a challenge getting that to work.
[49:44.450 --> 49:55.510]  One of the problems is that, is that pretty much no UNIX-like OS ships with a libresolve that natively supports DNSSEC signature validation.
[49:55.870 --> 49:59.310]  Um, so that's... that's a problem.
[49:59.310 --> 50:08.990]  Uh, I mean, DNSSEC is still pretty much like Terra Incognita, for most of the real world Internet out there that's not thinking of things in a laboratory setting.
[50:09.270 --> 50:28.270]  Uh, the other thing that we're going to need to try to do is restrict these policy records to be under 512 bytes, if possible, so that those records can go over UDP based, uh, DNS resolvers, and also so that certain network appliances won't drop them in transit for being too large.
[50:28.510 --> 50:29.390]  Thank you, Cisco.
[50:31.120 --> 50:47.260]  Our D-mail services, whether they're server-to-server or client-to-server, TLS version 1.2 is going to be mandatory, and it is also going to be mandatory that a cipher suite that supports perfect forward secrecy is being used.
[50:47.420 --> 50:53.400]  So that's something that's non-negotiable for people that are attempting to implement Darkmail clients and servers.
[50:53.740 --> 51:01.780]  The reference implementation will not support the really lame trustful mode that he described at the beginning.
[51:02.600 --> 51:06.420]  Um, that, again, probably no individuals really care about.
[51:07.040 --> 51:13.040]  Uh, and the Darkmail Alliance also plans to maintain a list of CAs for certificate validation.
[51:13.480 --> 51:26.620]  Uh, going to the client side, Volcano, remember the thick client here, it's important to note that this is a Thunderbird fork, it's not some sort of mega plug-in, and it is definitely the priority here.
[51:26.680 --> 51:33.680]  So, if we run out of resources, we're going to throw them all at Volcano and, and not the web, webmail client.
[51:35.200 --> 51:43.340]  We're going to be making changes both to the UI and to the native code of Thunderbird so that we can implement all this D-mail stuff at the protocol level.
[51:43.460 --> 51:55.600]  We plan to disable Thunderbird plug-ins, and we also are going to have a little bit of work to identify non-vital code paths that we can also disable for security purposes.
[51:56.160 --> 52:10.600]  Mostly the changes to Thunderbird in the GUI are going to be the way that Darkmail enabled messages are represented to the user so that they can distinguish between recipients that are on Darkmail protected domains.
[52:11.100 --> 52:15.090]  Also, senders that have sent mail that is Darkmail validated.
[52:15.740 --> 52:24.700]  Um, but as far as sending mail, there's not going to be any large changes between how you would normally go about sending mail versus how you would do it here.
[52:25.620 --> 52:32.100]  Finally, with the webmail, client-side crypto and doing it properly is going to be a big challenge.
[52:32.720 --> 52:34.900]  Um, a lot of controversy on that.
[52:35.000 --> 52:36.420]  This is not the time to get into it.
[52:36.600 --> 52:49.440]  And also, of course, loading JavaScript code into the interpreter from an untrusted server, uh, an equally problematic, uh, need that we're going to have to get to at some point.
[52:49.640 --> 52:56.500]  But that's pretty much a synopsis of what's going on and what we're going to be struggling to do over the next few months.
[53:03.050 --> 53:03.790]  Stay up here.
[53:05.770 --> 53:08.490]  We'll, we'll take questions in a minute if there are any.
[53:08.730 --> 53:23.950]  But I was just going to add that the goal is to actually take the protocol portions and build them separately so that they could be, in theory, up, adopted upstream for the people who like their Thunderbird plugins.
[53:24.450 --> 53:30.990]  Um, but Volcano is going to be stripped down, lean, mean, and focused on security because that's what we care about.
[53:31.210 --> 53:33.650]  And that's the type of client that we want to use.
[53:34.490 --> 53:38.990]  Um, I think that's pretty much all the time that we have.
[53:39.190 --> 53:57.230]  Um, I'll just close it by saying that hopefully at our next presentation, uh, in a few weeks out on the West Coast, we'll actually be able, or Steven will actually be able to demo, uh, what Volcano will look like when you're sending and receiving, say,
[53:57.510 --> 54:00.030]  a secure message versus a insecure message.
[54:00.190 --> 54:01.030]  At least that's the goal.
[54:01.770 --> 54:04.050]  Um, with that, thank you for your time.
[54:04.270 --> 54:07.010]  I'll be floating around for the next couple of days.
[54:07.410 --> 54:10.310]  So feel free to give me all your brilliant ideas for what I should do.