[00:00.000 --> 00:07.860]  If you want to find out more information, prismproof.org has links to all the specs, all the descriptions, all the design documents, etc.
[00:08.900 --> 00:18.200]  Now, I started this work very shortly after Glenn Greenwald's husband was harassed in Heathrow Airport.
[00:18.440 --> 00:36.440]  I mean, like, having been in the crypto world for 20 years now, having had my car searched three times on one trip to visit my parents shortly after I started working on web security, you know, when you start... I've always known that I've been under surveillance,
[00:36.660 --> 00:41.040]  but when you start targeting family, that was a step too far.
[00:41.300 --> 00:56.200]  So, I started looking at ways of disrupting the prison program, and then I bumped into Bruce Schneier who was at Harvard at the time and had just come back from Brazil having seen all the documents.
[00:56.780 --> 01:07.260]  And he basically said, well, you know, the NSA approach is, if they have option A, B and C, their approach is all of the above.
[01:07.980 --> 01:13.860]  So, if you're going to do any good, you can't just look at one program.
[01:15.080 --> 01:21.080]  You can't just stop PRISM because the NSA has dozens of them.
[01:21.080 --> 01:22.060]  Now there's hundreds.
[01:22.680 --> 01:24.180]  And it's not just one government either.
[01:25.020 --> 01:26.940]  Anybody recognize this woman?
[01:28.620 --> 01:29.820]  Anna Chapman.
[01:30.940 --> 01:32.840]  She came to one of my seminars.
[01:33.860 --> 01:35.660]  You know, she was local to Cambridge.
[01:36.440 --> 01:39.380]  You know, I go to seminars at MIT and Harvard.
[01:39.780 --> 01:41.460]  You know, she came to them.
[01:42.160 --> 01:46.320]  I've had my data sent in October by the Iranian Revolutionary Guard.
[01:46.320 --> 01:51.740]  You know, don't just work, you know, don't just focus on one government.
[01:52.060 --> 01:53.680]  You've got to protect against them all.
[01:54.540 --> 01:55.920]  And not just governments.
[01:56.700 --> 02:02.280]  If we're going to give people security, we've also got to give them security against those Internet criminals.
[02:04.060 --> 02:06.040]  And not just email either.
[02:06.520 --> 02:11.740]  If you're going to do something that's any good, it's got to be a platform that you can build on.
[02:11.740 --> 02:13.500]  So why start with email?
[02:14.040 --> 02:23.600]  Well, the answer is, from a technical point of view, from a protocol design point of view, email is the hardest protocol to secure.
[02:24.340 --> 02:32.660]  And the reason for that is, if you think about the way the email message system works, when you're sending a message, you send your message into the email system.
[02:33.220 --> 02:35.840]  And then you don't see anything else.
[02:36.080 --> 02:37.600]  You'll never see that message back.
[02:37.600 --> 02:42.000]  You might see another email message sent back to you, which is a bounce back.
[02:42.280 --> 02:45.280]  But you can't do any of the things that we'd normally do in TLS.
[02:45.680 --> 02:50.200]  You can't have a conversation saying, a negotiation of security parameters.
[02:50.440 --> 02:54.120]  You can't get the credentials from the person that you wanted to post to.
[02:54.740 --> 03:04.860]  So the upshot is that, if you can make email security really good and really easy to use, you can then take that mechanism.
[03:04.860 --> 03:06.380]  And you can apply it to VoIP.
[03:06.400 --> 03:07.380]  You can apply it to Chat.
[03:07.520 --> 03:10.340]  You can apply it to anything you want.
[03:12.580 --> 03:20.440]  And the goal here is to make Internet security ubiquitous for all 2 billion users of the Internet.
[03:21.560 --> 03:26.500]  Because if we do any less than that, we're not going to have PRISM-proof email.
[03:26.700 --> 03:28.660]  Because PRISM is metadata, right?
[03:30.020 --> 03:36.100]  Well, what's the most important piece of metadata that you use, that you're giving out when you're using PGP?
[03:37.620 --> 03:39.940]  You say, hey, I'm using encryption.
[03:40.540 --> 03:41.540]  Come look at me.
[03:41.620 --> 03:42.640]  I'm probably interesting.
[03:44.580 --> 03:49.320]  So, unless you're going to get everybody using encryption, you're not doing anything.
[03:50.260 --> 03:52.540]  So, I've been working for this a year.
[03:52.680 --> 03:54.040]  This is the launch.
[03:54.440 --> 03:57.260]  And it's now called Personal Privacy Environment.
[03:57.260 --> 04:02.860]  And we're wanting to give every user of the Internet ubiquitous security.
[04:03.320 --> 04:06.820]  Which is, of course, a problem that's like making lightning strike.
[04:07.240 --> 04:10.040]  You know, we've been trying to do this for 20 years.
[04:11.200 --> 04:12.680]  How are we going to do it different?
[04:14.560 --> 04:20.980]  Well, the answer is, let's copy from somebody who's already done it.
[04:21.720 --> 04:24.020]  Anybody recognize this guy, Tim Berners-Lee?
[04:24.840 --> 04:26.360]  He's the father of the web.
[04:26.640 --> 04:34.540]  I met him in 92, where he had 100 people working on the web, and saw a presentation that blew me away.
[04:35.020 --> 04:40.320]  A week later, I got a fellowship to work at CERN working on the web.
[04:41.640 --> 04:46.460]  And I became the security guy because I had a copy of Bruce Schneier's book.
[04:48.960 --> 04:54.080]  I also had kind of a form with some scary agencies.
[04:55.280 --> 04:58.680]  So, how did Tim make the web work?
[04:59.360 --> 05:09.280]  Well, the web succeeded where the other 20-odd network hypertext systems didn't because it was designed for deployment.
[05:09.280 --> 05:16.340]  It's not commonly known, but, you know, when we were at CERN, we were thinking about how could we make the web deploy.
[05:16.660 --> 05:23.760]  I used to run simulations to see, we've got two technical approaches, which one deploys better?
[05:24.900 --> 05:28.500]  You know, it wasn't an accident that we won and the other people lost.
[05:28.900 --> 05:31.000]  We built on open standards.
[05:31.420 --> 05:38.140]  HTML and HTTP were on the web, were available to all for free from the very start.
[05:38.740 --> 05:40.220]  We built on legacy.
[05:40.960 --> 05:45.900]  I had this argument with Tim when Tim was saying, well, you've got to use X.509 certificates.
[05:46.700 --> 05:48.980]  And I'm saying, have you seen ASN1?
[05:49.560 --> 05:52.160]  And he's kind of like, no, and I'm not going to.
[05:52.220 --> 05:52.560]  You are.
[05:53.580 --> 05:55.480]  And he said, well, you know, it's horrible.
[05:55.660 --> 06:00.320]  He said, yeah, but, you know, why do you think I used SGML in the web?
[06:00.320 --> 06:04.640]  Do you think I used SGML because I like SGML?
[06:05.140 --> 06:10.140]  I'm kind of like thinking, okay, no, yeah, yeah, you probably don't like it anywhere.
[06:10.760 --> 06:22.060]  The reason that the web was built on SGML was because the publishing industry had already decided to move to SGML as their interchange language.
[06:22.900 --> 06:24.920]  And that's the reason they chose SGML.
[06:24.920 --> 06:26.920]  The web was an open architecture.
[06:27.400 --> 06:30.860]  So it didn't tie people into one publication model.
[06:31.240 --> 06:35.860]  You know, at the time, there were people like Adobe who had Acrobat, and, you know, okay.
[06:36.240 --> 06:38.000]  And you had people like Hyper-G.
[06:38.820 --> 06:42.620]  They all had one idea of how you would use hypertext.
[06:43.000 --> 06:52.440]  What made the web different was it was an open architecture that allowed anybody to come along with their great idea and put it in and make use of it.
[06:52.760 --> 06:55.220]  And there was public domain reference code.
[06:55.440 --> 06:59.580]  Now, note I'm not saying open-source, because open-source wasn't invented for another...
[06:59.580 --> 07:01.140]  as a term for another five years.
[07:01.640 --> 07:05.480]  At the time, the only free software model was Copyleft.
[07:06.140 --> 07:11.540]  And the thing about Copyleft was it was designed to force people to make the code free.
[07:12.940 --> 07:15.520]  And Tim said, well, I don't want that.
[07:15.520 --> 07:25.200]  Because I want people to take my code, take the web, and embed it in for-profit applications.
[07:25.440 --> 07:33.960]  We want to have the web embedded in Windows, embedded in DEC VMS, embedded in Solaris.
[07:34.620 --> 07:39.200]  You know, I get very angry when people are saying, well, Microsoft stole the web.
[07:39.320 --> 07:48.720]  And you say, do you know, when I was at CERN, I spent three months begging Microsoft to use our system, to use our code.
[07:49.520 --> 07:55.020]  And yes, there were some good technical innovations in the web.
[07:55.160 --> 07:57.260]  In particular, URIs.
[07:57.820 --> 08:01.300]  URIs, the naming system, was good.
[08:01.620 --> 08:08.920]  But the biggest technical decisions, the most important ones, were actually what stuff we decided not to do.
[08:10.100 --> 08:16.220]  One of the things that had held back network hypertext, was a thing called referential transparency.
[08:16.880 --> 08:22.260]  And the idea was that whenever there was a hypertext link, and you clicked on it, it would go somewhere.
[08:22.940 --> 08:26.280]  It would go somewhere that the author of that document had intended.
[08:27.520 --> 08:29.640]  And Tim came along and said, well, no.
[08:31.060 --> 08:33.540]  You click on the link, if the stuff's there, you'll go to it.
[08:33.540 --> 08:36.700]  Otherwise, you'll get 404 not found.
[08:37.540 --> 08:41.880]  And why is that such an enormous technical advance?
[08:42.320 --> 08:51.840]  Well, the reason is that by avoiding this referential transparency problem, it meant that links could just be edited with a normal editor.
[08:52.180 --> 08:58.540]  You didn't need database-backed websites to serve just ordinary web pages.
[08:59.340 --> 09:12.140]  He cut out a huge number of problems with network hypertext by deciding that something that the whole field had decided was essential was actually kind of, eh, if people want it, do it.
[09:12.400 --> 09:13.280]  Same thing with index.
[09:13.700 --> 09:16.320]  The web did not have a built-in search mechanism.
[09:17.380 --> 09:21.400]  But pretty soon, a bunch of folk called Lycos built one.
[09:21.600 --> 09:25.180]  And then some folk called Google came along and did it better.
[09:26.820 --> 09:29.320]  And that's the template that I'm copying here.
[09:30.680 --> 09:34.400]  PPE is all built on open standards or proposed standards.
[09:34.680 --> 09:42.860]  You know, all the documents that I write, I maybe circulate them in private for a week just to make sure I don't put out a document that makes me look like a raving idiot.
[09:43.820 --> 09:43.900]  Yeah.
[09:44.620 --> 09:50.200]  Security is one of those fields that, you know, you put something out there and, you know, everybody comes and kills your baby.
[09:52.660 --> 09:54.220]  And they want...
[09:54.220 --> 09:55.220]  Yeah, yes.
[09:55.360 --> 09:56.620]  Yes, I do thank you for it.
[09:56.700 --> 10:00.840]  But, you know, I don't thank you for the miles of sarcasm you give.
[10:00.980 --> 10:04.140]  I mean, you know, I have a very fragile ego, you know?
[10:07.580 --> 10:09.900]  This design stuff is harder than it looks.
[10:09.900 --> 10:12.540]  So, it's all out there.
[10:13.000 --> 10:15.520]  And wherever possible, I'm building on legacy.
[10:15.840 --> 10:18.600]  And in particular here, I'm building on SMIME.
[10:18.940 --> 10:27.100]  And the reason for that is there are 5 billion email clients out there that can receive SMIME email.
[10:27.740 --> 10:34.400]  So, I'm going to build on that because I can send email to those clients and they'll read them now without any plugins.
[10:35.600 --> 10:39.120]  I'm perfectly happy to also add PGP.
[10:39.380 --> 10:40.640]  I've talked to Phil Zimmerman.
[10:41.200 --> 10:43.420]  I know how to do it.
[10:44.080 --> 10:46.680]  I just don't have time to do every last bit.
[10:49.460 --> 10:50.840]  An open-source code.
[10:50.940 --> 10:55.540]  Of course, all my code, all my reference code is on SourceForge.
[10:55.720 --> 10:56.780]  You can download it.
[10:56.840 --> 10:58.500]  The links are on prismproof.org.
[10:58.660 --> 11:02.700]  All the generators I use to synthesize the code from the specifications are up there.
[11:02.700 --> 11:03.460]  Everything.
[11:03.780 --> 11:05.900]  And yes, I have made some technical choices.
[11:07.560 --> 11:10.460]  I've got strong email addresses, which I'll come to in a moment.
[11:10.660 --> 11:12.460]  And I've punted on the hard stuff.
[11:12.960 --> 11:26.160]  There are some really hard problems that I've decided not to do in Phase 1 because those are problems that can be solved better as a layer on top of PPE rather than building it into things from Stage 1.
[11:27.180 --> 11:30.460]  So what we're doing here is dividing up the problem.
[11:30.920 --> 11:32.440]  There's two parts to PPE.
[11:33.280 --> 11:40.240]  One part is common infrastructure that anybody who's developing a new messaging scheme could, in principle, share.
[11:41.320 --> 11:42.720]  Mail system integration.
[11:42.960 --> 11:49.880]  If we're going to have a new mail encryption scheme, you're going to have to extend Outlook, Windows Live Mail, Thunderbird, and so on.
[11:50.500 --> 11:53.000]  Well, that's all work that we can share.
[11:53.800 --> 11:56.700]  You're going to have to have an infrastructure for distribution of keys.
[11:57.240 --> 12:00.720]  Well, you know, web services pretty much all look the same.
[12:00.880 --> 12:02.980]  I mean, like, that's another piece that we can share.
[12:03.160 --> 12:09.520]  So let's build some stuff here that we can all share as infrastructure to enable Internet users.
[12:10.480 --> 12:29.120]  And then this other piece that we really like doing, you know, the interesting stuff to me, like trust models and transport that is protected against traffic analysis, that's areas where, you know, let five different people go off and do five different things because,
[12:29.340 --> 12:33.660]  you know, none of us know absolutely which one's going to be best.
[12:34.080 --> 12:37.220]  So the way that I divide it up is dessert.
[12:37.540 --> 12:40.340]  You know, this is the part that I want to be doing.
[12:40.560 --> 12:41.280]  That's my dessert.
[12:41.420 --> 12:42.560]  That's the bit that I want.
[12:44.500 --> 12:50.400]  But to make the stuff useful, you know, you've got to eat up your meat and two veg.
[12:52.520 --> 12:56.580]  And so, you know, I spent a year eating meat and two veg.
[12:57.820 --> 13:00.280]  And yes, you know, please steal stuff.
[13:00.280 --> 13:03.740]  Anyway, you know, this is not about do it my way.
[13:04.700 --> 13:06.860]  Please take this stuff and make use of it.
[13:06.920 --> 13:19.680]  And, you know, the objective here is to get Microsoft and Google and Apple and all those providers of mail applications to take this stuff and embed it in the stuff they're providing to actual consumers.
[13:20.280 --> 13:22.820]  And the reason I'm here is to recruit.
[13:24.000 --> 13:26.160]  Because, you know, I'm one person.
[13:26.160 --> 13:29.040]  I can only write code at a particular speed.
[13:30.040 --> 13:34.480]  If we're going to make this happen, we need a lot of people involved.
[13:34.620 --> 13:37.880]  You know, we need people to use it and see whether it actually works.
[13:38.020 --> 13:39.340]  We need people to test it.
[13:39.380 --> 13:40.600]  We need people to write code.
[13:40.700 --> 13:42.480]  And not just crypto code.
[13:42.720 --> 13:45.980]  If there are people who are crypto coders, yeah, great, you know.
[13:46.400 --> 13:49.160]  But there's a lot of UI code that also would need, you know.
[13:49.160 --> 14:00.440]  If we're going to make this happen, we have to modify every Internet mail client eventually so that it's built in and people can just make use of it without thinking.
[14:02.100 --> 14:09.840]  And, you know, maybe most important of all, evangelists, people will go to the likes of Microsoft and Sun and so on and say, hey, this is this stuff.
[14:09.980 --> 14:10.600]  We're using it.
[14:10.680 --> 14:12.160]  Please support it.
[14:13.280 --> 14:13.800]  Okay.
[14:14.840 --> 14:21.200]  So, we've got a...one of the things I've got to do is to convince people that this is possible.
[14:22.040 --> 14:30.940]  And one of the objections that was made was, well, you know, when you were starting the web, network hypertext was actually 30 years old.
[14:33.060 --> 14:36.600]  You know, Ted Nelson came out with Xanadu in 1960.
[14:36.600 --> 14:41.740]  So, Tim was plowing a well dug furrow.
[14:42.320 --> 14:44.400]  Well, here's the really strange thing.
[14:44.940 --> 14:47.440]  We already have email encryption.
[14:47.760 --> 14:58.880]  If you have an iPhone in your pocket, if you use any of the common desktop email clients, you've had email encryption built in for 15 years.
[14:59.480 --> 15:01.900]  But almost nobody uses it.
[15:02.060 --> 15:05.860]  How many people here have used encrypted mail in the past week?
[15:07.560 --> 15:08.200]  Okay.
[15:09.080 --> 15:14.860]  How many people here use encrypted mail every single day?
[15:16.560 --> 15:17.200]  Yeah.
[15:17.360 --> 15:19.140]  I mean, like, some folk...
[15:20.160 --> 15:26.920]  And this is the audience where, you know, surely every hand should be going up if we've done the job right.
[15:27.760 --> 15:29.720]  So, what hasn't happened?
[15:29.840 --> 15:30.560]  You know, what went wrong?
[15:30.740 --> 15:32.880]  Well, there are a bunch of historical things.
[15:32.880 --> 15:40.380]  You know, back in 92 when I started working on the web, you know, and I was doing the password authentication piece.
[15:40.500 --> 15:46.240]  You know, the client auth piece in HTTP is the way it is because RSA was patented.
[15:46.380 --> 15:47.580]  All public key was patented.
[15:47.580 --> 15:50.860]  So, I couldn't use techniques that I really wanted to use.
[15:51.880 --> 15:53.480]  Patents are no longer a problem.
[15:53.660 --> 15:57.440]  You know, we've had public key cryptography out of patent for 15 years now.
[15:58.160 --> 15:59.640]  Limited machine capabilities.
[15:59.840 --> 16:08.820]  If you look at the design of SMIME and PGP, they're both designed at a time when doing a public key crypto operation took time.
[16:09.460 --> 16:13.540]  You know, you would wait a significant length of time to do just one of them.
[16:13.780 --> 16:20.260]  So, doing a fancy PKI chain of trust, you know, that really wasn't going to happen.
[16:20.940 --> 16:22.960]  Today, you can do RSA.
[16:23.640 --> 16:29.760]  You can do pretty much any of the public key operations on the client side and it just happens and nobody's noticing.
[16:31.040 --> 16:37.180]  The other two pieces, I mean, like, a year ago, I'd have written the crypto wars off.
[16:37.300 --> 16:38.660]  You know, I'd have said, you know, they were over.
[16:38.860 --> 16:41.980]  You know, we don't get harassed by the NSA anymore.
[16:42.240 --> 16:45.360]  But, okay, well, ho-hum.
[16:46.680 --> 16:49.920]  But one of them is still with us and that's the standards wars.
[16:50.700 --> 16:54.080]  And, you know, this is a... I'll get to that in a second.
[16:54.800 --> 16:55.940]  So, what's going on here?
[16:55.940 --> 17:01.800]  Well, in any of these email encryption schemes, we're basically using a public key infrastructure approach.
[17:02.060 --> 17:06.180]  We use digital signatures to authenticate people's keys.
[17:06.720 --> 17:10.300]  We then use public key encryption to exchange symmetric keys.
[17:10.300 --> 17:14.440]  And we use those symmetric keys to encrypt the actual data we're interested in.
[17:14.840 --> 17:20.240]  And this approach has been applied numerous times to email, starting in 1993.
[17:20.500 --> 17:23.120]  Anybody ever use here... anybody ever use PEM?
[17:25.680 --> 17:26.140]  Maybe...
[17:26.140 --> 17:27.720]  Yeah, I mean, like...
[17:28.280 --> 17:32.660]  Okay, they had this model and they had this hierarchy of certificate authorities that never happened.
[17:32.840 --> 17:36.220]  Where you'd have this root of root certificate authorities that would do...
[17:36.220 --> 17:39.120]  Would issue a certificate to sub-CAs.
[17:39.900 --> 17:43.180]  And there would be sub-CAs underneath them and turtles all the way down.
[17:43.300 --> 17:48.120]  I mean, I can't quite remember the nomenclature.
[17:48.120 --> 17:49.960]  But this is the one that I've got.
[17:50.100 --> 17:50.620]  You know, kings.
[17:50.940 --> 17:52.260]  And you probably can't see it.
[17:52.320 --> 17:56.460]  At the bottom here, we've got serfs, peasants, and dirty, smelly hippies.
[17:59.180 --> 18:09.400]  So, not surprisingly, perhaps, you know, PEM is one of those products that is best known for the responses that it led to.
[18:09.980 --> 18:12.420]  Most important of these being PGP.
[18:12.740 --> 18:17.480]  You know, Phil Zimmerman took a look at the PEM model and said, Hey, that's never going to happen.
[18:18.320 --> 18:20.420]  And if it does, I don't want it to happen.
[18:20.780 --> 18:24.700]  And the thing about the PGP web of trust is that everybody is a peer.
[18:25.800 --> 18:37.320]  And at about the same time, RSA was reworking PEM and those ideas to create SMIME, which was integrated with the new ITF mail system MIME.
[18:37.680 --> 18:43.400]  And they had a brainwave of, Oh, you don't have to have one root of roots at the top.
[18:43.640 --> 18:45.620]  There could be multiple CAs.
[18:46.600 --> 18:49.860]  And so, you know, there was a division of opinion.
[18:52.740 --> 18:57.560]  Now, PGP, however, had a better marketing department.
[18:57.740 --> 18:58.360]  And it was this guy.
[18:58.420 --> 19:00.060]  And he didn't even want to be marketing PGP.
[19:00.960 --> 19:05.060]  This is Louis Free, probably most useless director of the FBI ever.
[19:06.620 --> 19:23.760]  And I can say that because not only did he spend his time railing against the use of strong cryptography, when the inquisitions, you know, when the inquiries came into 9-11, it became apparent that the reason that he never understood why the hacker community,
[19:23.920 --> 19:31.200]  why the crypto community was so worried about what he was saying, was because he just didn't understand what computers could do.
[19:31.780 --> 19:38.440]  The FBI was using a bunch of rubbish computers that had been last developed in, you know, in the 1960s.
[19:38.620 --> 19:43.260]  They had a search system that allowed them to search at one term at a time.
[19:44.580 --> 19:55.260]  So the reason that they didn't see the privacy risks that we all saw was because they were operating in the 1960s and weren't taking advantage of any of this technology.
[19:57.700 --> 20:03.440]  But the long-term consequence is we've had a 15-year standard stalemate.
[20:03.440 --> 20:08.420]  And we've got a situation where, you know, it's like the VHS Betamax thing.
[20:08.580 --> 20:15.800]  Only this time, instead of it being one by one side, both sides have had a victory of sorts.
[20:16.460 --> 20:20.760]  SMIME is deployed in five billion email clients.
[20:21.020 --> 20:32.960]  If you download Outlook, Windows, Live Mail, Thunderbird, whatever, apart from Android mail client, everything comes with SMIME already built in.
[20:35.360 --> 20:40.660]  But the product that has the mind share is PGP.
[20:41.280 --> 20:44.380]  And this has been going on now for 15 years.
[20:45.380 --> 20:46.260]  Neither has one.
[20:46.260 --> 20:50.740]  I don't think neither can win because SMIME has this problem.
[20:50.740 --> 20:52.440]  It's too hard to get the certificates.
[20:53.060 --> 20:57.120]  And then once you've got the certificates and you've installed them, well, they expire in a year.
[20:58.560 --> 21:00.240]  And you've got to do it all over again.
[21:01.180 --> 21:03.000]  And it's just too much hassle to use.
[21:03.140 --> 21:06.180]  You know, you have to click this button to say, encrypt this message.
[21:07.520 --> 21:11.420]  And, you know, you're laughing, but, you know, you talk to the Apple guys.
[21:13.260 --> 21:19.760]  Clicking one button to say, I want this encrypted, that is too much for Apple usability folk.
[21:20.700 --> 21:22.160]  And you know what?
[21:22.620 --> 21:23.820]  They're right.
[21:25.000 --> 21:35.720]  If we want everybody to use encrypted mail all the time, encrypted mail must be as easy to use as regular mail.
[21:36.620 --> 21:39.100]  Absolutely no additional effort.
[21:45.460 --> 21:46.260]  PGP...
[21:46.260 --> 21:51.940]  Well, first of all, there's a problem that nobody can understand it unless they're kind of like a geek.
[21:53.440 --> 21:55.880]  But again, it's just too much hassle to use.
[21:56.040 --> 22:00.660]  I mean, I've had both of them, but I get very little encrypted mail.
[22:02.240 --> 22:03.440]  They're just too much hassle.
[22:04.440 --> 22:05.780]  So here's the solution.
[22:06.960 --> 22:12.680]  You know, if VHS versus Betamax had gone on until the 90s, this is what would have happened.
[22:13.560 --> 22:15.860]  DVD would have come out and replaced both.
[22:15.860 --> 22:24.100]  And what we've got to be thinking of is not which is going to work, but what email infrastructure do we want?
[22:24.640 --> 22:31.380]  What's the next generation that's going to replace both of them and make email actually usable?
[22:31.920 --> 22:36.000]  And to do that, we've got to achieve what I call frictionless security.
[22:36.660 --> 22:42.080]  It's got to require absolutely no additional effort to use secure mail.
[22:42.540 --> 22:50.060]  No additional configuration effort, no conditional steps when it's in use, and no maintenance, no renewals.
[22:50.240 --> 22:58.820]  The only time you can ever tread on the user and have them do something is when that user decides, I'm sending this letter to a very important person.
[22:59.100 --> 23:01.660]  Maybe I'm sending a letter to my lawyer.
[23:02.500 --> 23:04.960]  Maybe it's the bank that's sending me my statement.
[23:05.340 --> 23:09.800]  And they want to make sure that it is sent encrypted or not at all.
[23:10.620 --> 23:14.880]  That's the only time in which we will allow the user to be interrupted.
[23:15.620 --> 23:19.380]  And that's what we're doing now with PPE 0.1.
[23:19.640 --> 23:23.340]  At the moment, I've only got deep integration for Windows Live Mail.
[23:23.520 --> 23:31.660]  You can use the code with any mail client of your choice, but it's only frictionless for configuration if you're using that one product.
[23:31.840 --> 23:34.840]  And the reason for that is, you know, I can only type so fast.
[23:36.860 --> 23:50.640]  So, if you're using the reference code, to configure your client to receive encrypted mail, all you do is you run the key manager, and that will generate your personal PKI hierarchy.
[23:50.640 --> 23:51.680]  I'll come to that in a second.
[23:51.680 --> 23:55.800]  It will generate a strong email address, the finger, and the recovery codes.
[23:56.000 --> 23:58.780]  Everything you need to have your own personal PKI.
[23:59.540 --> 24:04.660]  It will then configure your mail client to use the certificates it's generated.
[24:05.240 --> 24:06.460]  It will push...
[24:06.460 --> 24:09.820]  There's one thing at the moment that's a bit of a hack, which is you've got...
[24:09.820 --> 24:12.820]  I've got this data that other people need to connect...
[24:12.820 --> 24:14.720]  access to be able to talk to you.
[24:14.880 --> 24:18.080]  And that has to be published on a web server somewhere.
[24:18.260 --> 24:19.700]  It doesn't matter which web server it is.
[24:19.700 --> 24:25.260]  It doesn't need to be a trusted web server, but it needs to be published somewhere using the well-known protocol.
[24:26.120 --> 24:28.400]  And at the moment I don't have that automated.
[24:28.780 --> 24:32.280]  This is obviously something that could be automated in 10 minutes with a Perl hack.
[24:33.660 --> 24:35.020]  I've not had time to do that.
[24:36.460 --> 24:44.340]  And now anybody in the world can send you encrypted mail and be convinced that they're sending you the mail encrypted or not at all.
[24:44.340 --> 24:48.640]  And it will work with 95% of the email clients out there.
[24:50.000 --> 24:54.800]  No effort required on the user at all to receive that encrypted mail.
[24:55.140 --> 24:59.340]  And that's because we're leveraging that SMIME layer that's already built into the clients.
[24:59.940 --> 25:01.660]  No need to put in a plug-in.
[25:05.280 --> 25:18.540]  And again, you know, if there's anybody out there who knows these other products, I mean, yeah, it's not that long to do each one, but taking the time to learn which each one does, you know.
[25:19.880 --> 25:21.700]  So personal PKI, what's that?
[25:21.800 --> 25:27.840]  The idea here is let's correct one of the biggest mistakes that was made in the PEM hierarchy.
[25:27.840 --> 25:32.440]  You know, the PEM hierarchy did have a good idea which was a route of trust.
[25:33.100 --> 25:35.220]  But they had the wrong person at the route.
[25:35.580 --> 25:40.320]  You know, they had the, you know, some faceless government bureaucracy or whatever.
[25:40.920 --> 25:45.320]  There's only one person who should be in charge of your personal route of trust.
[25:45.440 --> 25:46.080]  And that is?
[25:47.980 --> 25:48.460]  You.
[25:49.720 --> 25:51.740]  So you're going to have a personal PKI.
[25:52.440 --> 26:00.620]  And here, I'm using the same approach that we used when we rolled out the VeriSign PKI back in the 95.
[26:00.820 --> 26:04.540]  I was a principal scientist there for a dozen years.
[26:05.180 --> 26:07.160]  So this is exactly what we did there.
[26:07.300 --> 26:13.680]  We have, in the VeriSign PKI, there's an offline master that never touches the Internet.
[26:13.820 --> 26:16.040]  And that's used to assign an online key.
[26:16.040 --> 26:19.840]  And then the online keys are used to assign use keys.
[26:20.120 --> 26:28.740]  And the use keys are what the user actually going to be using for encryption and authentication.
[26:29.980 --> 26:36.540]  Now, your encryption key, you're probably going to want to be able to receive your email on more than one device.
[26:36.540 --> 26:42.260]  I was counting up the number of devices I receive email on, and it's actually six.
[26:43.420 --> 26:49.720]  You know, because I've got three desktops, two tablets, two...oh, seven.
[26:53.280 --> 26:54.460]  You know, they multiply.
[26:54.920 --> 27:05.900]  And if using encrypted mail is going to be as easy as using regular mail, you're going to have to be able to read an encrypted message that somebody has sent to you on any of those machines.
[27:05.900 --> 27:14.680]  Which means that your encryption key, or rather your decryption key, has to be magically installed in every one of the machines you use.
[27:15.460 --> 27:29.480]  Also, as soon as you put an encryption key on something like an iPhone or a tablet, anything that's mobile, anything that can get lost, you're probably going to want to have some way of having some control over that key.
[27:29.480 --> 27:36.620]  And the best way to have control over an encryption key is to limit the length of time that you let people use it to send you encrypted mail.
[27:38.100 --> 27:43.080]  So you probably want to be cycling your encryption keys maybe once a month.
[27:43.920 --> 27:45.960]  But you want to have it all happening automatically.
[27:46.420 --> 27:48.620]  This is not something the user should ever see.
[27:48.620 --> 28:01.460]  One of the guiding principles of all this is, this is absolutely platinum-plated, the very state-of-the-art, top-level cryptography that we would give to the best customers.
[28:01.940 --> 28:03.460]  And we're giving it to everybody.
[28:03.700 --> 28:05.880]  So there's no compromise in the security.
[28:05.880 --> 28:12.360]  I don't believe that there's a difference between sophisticated users and ordinary users.
[28:12.720 --> 28:13.960]  Because, you know what?
[28:14.160 --> 28:18.900]  All this stuff here is there because people make mistakes.
[28:19.040 --> 28:27.180]  The reason you have an offline and online key is because machines get compromised, and you really don't want your master key to be compromised.
[28:28.900 --> 28:34.520]  The reason that you split encryption authentication keys is because devices get lost.
[28:35.920 --> 28:44.520]  And so, you know, are ordinary users more or less likely to be using their keys than sophisticated ones?
[28:46.420 --> 28:48.980]  So, strong email addresses, what's that?
[28:49.580 --> 28:52.560]  Okay, you have your personal master key.
[28:52.900 --> 28:55.440]  We take a fingerprint of that.
[28:55.700 --> 28:57.640]  It's not quite a PGP fingerprint.
[28:57.960 --> 28:59.400]  You know, we've now got Base64.
[29:00.000 --> 29:04.280]  Base64 allows us to use more bits and the same length of data.
[29:04.280 --> 29:12.460]  We take that and we simply prepend it onto an email address with a question mark in between.
[29:12.600 --> 29:19.000]  The reason the question mark is chosen is because question mark turns out to be a legal email address character.
[29:19.580 --> 29:24.740]  However, it is an illegal account character on every operating system.
[29:26.260 --> 29:28.620]  Yeah, you guys in this room are the reason.
[29:31.760 --> 29:36.260]  So, the format here is fingerprint, question mark, account at domain.
[29:37.000 --> 29:39.900]  Actually, the domain is not necessarily the domain of your mail server.
[29:40.220 --> 29:44.220]  If you can publish your fingerprint on the mail server that you're using, great.
[29:45.480 --> 29:51.320]  Otherwise, you might have to publish your fingerprint somewhere else and people have it, have people download it.
[29:51.320 --> 29:57.660]  So, here we have the fingerprint, which in this case is the fingerprint of Alice's personal PKI hierarchy.
[29:57.900 --> 30:05.060]  This is a fingerprint that, hopefully, Alice does not need to be forced to change ever.
[30:05.560 --> 30:12.080]  So that she can do things like have it QR code encoded on that on her iPhone.
[30:13.440 --> 30:19.260]  So that, you know, when she's wanting to give it to somebody else, she can just whip out her iPhone and hand over the fingerprint.
[30:21.340 --> 30:23.580]  Account, well, you need to know where to send the mail to.
[30:24.260 --> 30:24.880]  Okay.
[30:25.460 --> 30:29.420]  The fingerprint is used to retrieve the finger.
[30:29.980 --> 30:43.560]  And the finger is just a JSON data structure that contains all the certificate chain, all the information that a client needs to validate a use key and decide how to send encryption.
[30:43.900 --> 30:48.830]  And this is the point at which, you know, at the moment I've got it coded up for SMIME.
[30:48.830 --> 30:54.150]  It'd be really easy to code it so that you could support PGP as well.
[30:55.490 --> 31:07.530]  And it has policy statements which are saying things like, okay, if you want to send me email, then you want to send SMTP to this file, to this server, and it's got start TLS on it.
[31:08.070 --> 31:12.990]  You know, we're using end-to-end security, but there's no need to forget about transport security as well.
[31:13.310 --> 31:17.030]  Oh, and here's the fingerprint of the key for the TLS cert.
[31:18.090 --> 31:23.650]  SMIME is preferred, and here's the certificate, here's the key.
[31:24.650 --> 31:31.130]  And if you're a VIP, well, and you've been pre-approved, then here's another certificate you might be using.
[31:33.730 --> 31:54.870]  One of the things that you start to realize when you design this stuff is, okay, if I'm going to turn on email encryption, and everybody in the world suddenly starts sending me encrypted mail, that might not be an unmitigated success until I've got every one of my devices enabled so that I can receive encrypted mail.
[31:55.110 --> 32:01.790]  So one of the policy pieces here allows somebody to say, hey, yes, I have set up every device on which I read email.
[32:02.850 --> 32:05.010]  Now encrypted email is preferred.
[32:06.030 --> 32:08.590]  So that's the current state of the key manager.
[32:09.070 --> 32:15.890]  In the next release, we're hoping, you know, making the publications of the website will become automatic.
[32:16.170 --> 32:17.990]  It will also have an option.
[32:18.890 --> 32:25.330]  I emphasize that this will be an option to enroll your certificate in a key server infrastructure.
[32:26.470 --> 32:31.370]  One of the things my employer has been doing now is giving away free SMIME certs.
[32:31.690 --> 32:39.990]  So, you know, there's that certificate server there, and they gave me the protocol for how to talk to it, so I'm going to build that into the key manager.
[32:41.810 --> 32:45.350]  I also want to start making use of Google certificates transparency.
[32:45.650 --> 32:47.070]  Has anybody been familiar with that project?
[32:48.190 --> 32:58.830]  I've not got time to pricey it now, but it's really amazing stuff, and Ben, Laurie, and co are really doing great technology there that I want to embed here.
[32:59.370 --> 33:02.850]  And it also can be used to register your secret keys.
[33:03.910 --> 33:09.120]  So the idea here is you run the key manager, and it will encrypt the encryption key...
[33:09.890 --> 33:12.750]  Sorry, encrypt the decryption key and upload it to the server.
[33:13.250 --> 33:14.910]  Now, why would you want to do that?
[33:14.910 --> 33:31.590]  Right, well, then we can transport that key into all the other devices that you're using, and because it was stored encrypted, because we chose a random number for the decryption key and not a passphrase, we can do it securely.
[33:32.250 --> 33:38.590]  And this is obviously going to support the telling people that encrypted emails preferred.
[33:39.290 --> 33:40.990]  Okay, so that's receiving a mail.
[33:41.190 --> 33:43.030]  Well, what do you want to do when you're sending a mail?
[33:43.030 --> 33:48.190]  Well, and here's the point where, okay, you can still run your existing mail client.
[33:49.470 --> 33:54.790]  You don't need to put a plug-in that changes the code of the web client itself.
[33:55.150 --> 33:59.970]  But I do need a hook that I can change the bits on your wire.
[33:59.970 --> 34:03.550]  And what that hook is, is a proxy.
[34:03.830 --> 34:06.070]  It's an outbound SMT mail proxy.
[34:06.450 --> 34:10.330]  And it basically takes all the mail from...
[34:10.330 --> 34:17.510]  The mail client is configured to pipe all the outputs, all the outbound mail through this mail, this proxy.
[34:17.850 --> 34:22.330]  And then Peep sits there and decides, oh, can I encrypt that message?
[34:22.330 --> 34:25.550]  If so, I'll encrypt it before it sends us off.
[34:26.190 --> 34:32.130]  Now, this is a trusted proxy, which is obviously not an end-to-end solution.
[34:32.330 --> 34:39.490]  Unless you happen to be running Peep on the same machine that your email client is running on.
[34:39.610 --> 34:42.830]  Ideally, I would hope people would run this on the same machine.
[34:43.610 --> 34:48.690]  I have got TLS turned on, just in case people don't, but yeah.
[34:50.050 --> 34:53.430]  So the current version is just looking for strong email addresses.
[34:53.850 --> 34:58.930]  And whenever it sees a strong email address, it will then encrypt the data.
[34:59.510 --> 35:07.650]  Well, it realizes it must be sent encrypted, retrieves the finger from the web, and encrypted the message as directed.
[35:07.990 --> 35:14.470]  At the moment, it's only doing SMIME, but it would be easy to add PGP if there was a PGP lib hacked in.
[35:15.110 --> 35:26.050]  And what I want to do for 1.0 is to check every outbound address, query a service in the cloud, and say, hey, I'm sending this message to this user.
[35:26.250 --> 35:30.710]  Do you have a key that allows me to send this message encrypted?
[35:31.270 --> 35:38.710]  And this is, of course, where you're introducing possibility of third parties, and obviously that service is going to be a trusted one.
[35:38.710 --> 35:45.670]  It might be a trusted service that you install and run for you yourself.
[35:46.130 --> 35:55.470]  It might be a trusted service that was provided by the likes of the Symantec, or a Komodo, or whoever, who happened to be in the antivirus protection business.
[35:57.610 --> 36:10.030]  So in the PEEP 1.0, we will then have achieved the test bed on which people can start to explore new trust models and new message transports.
[36:10.250 --> 36:17.150]  When the key manager runs, it will push the key to a key broker via this omnipublish protocol.
[36:17.830 --> 36:26.870]  When the mail sender is, you know, either PEEP or hopefully someday we'll start to get mail clients that have that functionality built in.
[36:27.090 --> 36:32.550]  When it's trying to send a message, it will send a query over there saying, do you have keys?
[36:33.310 --> 36:39.930]  Maybe you don't wait until... if you've got deep integration with the mail client, maybe you don't wait until the mail needs to be sent.
[36:39.930 --> 36:51.610]  Maybe what you would do is look at the contacts directory, download all the fingers for every contact there, and just store them locally.
[36:51.990 --> 36:58.170]  Again, you know, this is something that some PGP implementations have done for a while.
[36:58.610 --> 37:12.150]  This is making it more systematic, and instead of doing it in one protocol that requires plugins, we're doing it for any protocol and leveraging that deployed base of 5 billion clients.
[37:13.530 --> 37:22.770]  Okay, oh, so here, between these, that's the piece where interesting stuff on trust models can go.
[37:24.330 --> 37:33.230]  Because you've got a well-defined API to talk to the key managers, well-defined API to talk to key users.
[37:34.470 --> 37:36.990]  You can then stick anything between those points.
[37:37.370 --> 37:41.430]  And you can start testing it out and seeing whether it works in practice.
[37:41.850 --> 37:57.230]  Now, to achieve your desired security properties, you may be forced to eventually push that infrastructure down into the actual mail client to achieve your full end-to-end capabilities.
[37:57.670 --> 38:01.850]  But you'll be able to see whether it works using the PEEP testbed.
[38:04.010 --> 38:08.810]  Okay, so we've done how do we do...
[38:09.410 --> 38:11.790]  We've done how we've got the testbed up.
[38:14.150 --> 38:20.210]  And we've done, obviously, you've got SMIME, so you can do your regular certificate authority chain of trust right stuff.
[38:21.570 --> 38:24.170]  How would we be doing endorsement?
[38:24.290 --> 38:27.310]  You know, how do we get a peer-to-peer system working?
[38:27.870 --> 38:32.730]  And this is something that I think that we can revisit PGP.
[38:33.410 --> 38:41.170]  You see, when PGP was coming out, well, we were sending and receiving mail from devices that were static.
[38:41.810 --> 38:48.390]  You know, if you've got a Vax 11 780, you know, you don't put that in your pocket and walk around with it.
[38:49.190 --> 38:50.690]  It doesn't have a camera.
[38:51.170 --> 38:53.310]  It can't read a QR code.
[38:53.710 --> 39:02.710]  And I think that if we're going to make a peer-to-peer key distribution system work, you know, these things have cameras on them.
[39:03.130 --> 39:04.730]  They can read a QR code.
[39:04.830 --> 39:08.150]  We could express a strong email address as a QR code.
[39:08.750 --> 39:19.370]  Wouldn't that be a really cool way of being able to give somebody your strong email address, so that then they can send you encrypted mail and nobody can futz with it?
[39:20.950 --> 39:32.730]  Now, that said, you know, this is research, so please don't read the 0.1 version of the specs and go out and laser print your phone and then blame me if we change things.
[39:33.950 --> 39:34.430]  Yeah.
[39:36.190 --> 39:36.670]  Okay.
[39:37.290 --> 39:40.370]  Coming to the end here, hopefully we'll have time for questions.
[39:41.490 --> 39:46.350]  The one question, though, I've been asked by absolutely everybody is, oh, spam!
[39:46.750 --> 39:49.650]  You know, it's kind of like one of those things that you're starting to talk to these things.
[39:49.810 --> 39:50.110]  It's kind of like...
[39:50.950 --> 39:56.030]  As soon as I've got ten words in, there's somebody in the room who says, oh, no, no, you can't do end-to-end email.
[39:56.350 --> 39:56.710]  Spam!
[39:57.130 --> 39:57.490]  Spam!
[39:58.170 --> 39:59.130]  Can't do end-to-end!
[39:59.130 --> 40:11.970]  And, you know, well, actually, if you're going to have end-to-end email, encryption, obviously the spam filter is not going to be able to do spam filtering by doing content analysis.
[40:13.110 --> 40:14.070]  Well, guess what?
[40:14.190 --> 40:19.830]  You know, I spent a lot of time doing spam, you know, because spam was a security issue when it first appeared.
[40:20.770 --> 40:29.290]  Very, very few commercial spam filters use content analysis as the basis for their spam protection services.
[40:29.770 --> 40:35.050]  Yes, it is possibly an input to the filter, but not necessarily.
[40:35.430 --> 40:37.830]  But this is never the only input.
[40:38.330 --> 40:46.150]  You know, if your spam filtering depends upon content analysis alone, you're reading a lot of spam.
[40:47.710 --> 40:51.710]  So, yes, it is an issue, but you know what?
[40:51.710 --> 40:58.070]  If you can't use end-to-end email encryption, well, don't.
[41:00.430 --> 41:04.050]  Give the spam filter a key.
[41:05.490 --> 41:10.290]  Encrypt... tell people to encrypt their mail by default to that spam filter.
[41:10.770 --> 41:21.690]  And for the few people who you know and trust not to send you spam, give them a different strong email address that doesn't go through the spam filter.
[41:21.890 --> 41:22.570]  Problem solved.
[41:24.770 --> 41:25.890]  So, in conclusion...
[41:26.650 --> 41:28.730]  Oh, this was another version.
[41:29.190 --> 41:36.950]  Yeah, it's kind of like once you've got an acronym out there, you're kind of like stuck with the initials, but...
[41:36.950 --> 41:37.550]  Yeah.
[41:37.870 --> 41:45.010]  So, basically, we've got secure email encryption, and the security is all resting on stuff that is well tried and tested.
[41:45.390 --> 41:48.270]  You know, this is all based on ITF specs.
[41:48.610 --> 41:53.630]  You know, the security rests on ITF specs that have been out there and tested for decades now.
[41:55.330 --> 42:00.050]  But we've added frictionless security that requires no user effort at all.
[42:00.830 --> 42:08.370]  So, we've got a proof of concept out there, and what I'm asking for here is help to make that a reality in the world.
[42:08.370 --> 42:09.430]  Thank you very much.
[42:13.990 --> 42:15.910]  And we have some time for some questions.
[42:22.340 --> 42:22.720]  Okay.
[42:23.700 --> 42:36.080]  It's become abundantly clear that end-to-end encryption is important, but that, really, to be Prism-proof, we'd have to protect ourselves from showing our metadata.
[42:37.000 --> 42:37.300]  Right.
[42:38.180 --> 42:38.580]  Okay.
[42:38.900 --> 42:41.800]  So, I've not really had chance...
[42:41.800 --> 42:43.240]  Yeah, this is one of the...
[42:43.240 --> 42:47.860]  So, to go to full Prism-proof, I described this on the web.
[42:48.160 --> 42:54.800]  You know, basically, that is the endpoint that we're working towards, rather than something that we can deliver this year.
[42:54.880 --> 42:55.920]  You know, this is all stuff...
[42:55.920 --> 43:01.160]  The stuff I described here, this is all stuff you can download and use today, and it works.
[43:01.360 --> 43:01.500]  Okay.
[43:01.900 --> 43:03.960]  So, how do we get to the point where we've got...
[43:03.960 --> 43:05.700]  Well, first of all, you've got to do a couple of things.
[43:06.540 --> 43:10.760]  First of all, encrypting the transport between the mail servers.
[43:11.260 --> 43:16.080]  And the thing about the finger, we've now got an infrastructure that allows you to tell...
[43:16.080 --> 43:21.020]  That allows an outbound mail server to ask, Hey, I'm going to send mail to this party.
[43:21.640 --> 43:25.980]  Is there a TLS certificate for that mail server that I want to connect to?
[43:26.320 --> 43:27.960]  And the Omnibroker...
[43:28.540 --> 43:31.260]  I've not had time to go through the full architecture.
[43:31.260 --> 43:33.940]  But the Omnibroker component allows you to...
[43:33.940 --> 43:38.380]  That outbound mail server to query and say, Hey, can I use TLS to talk to them?
[43:38.720 --> 43:42.200]  And the back will come and say, Yes, use TLS, and this is the pin cert.
[43:42.440 --> 43:43.380]  So that's one part.
[43:43.960 --> 43:46.200]  So you can get the transport layer security.
[43:46.880 --> 43:48.380]  Now, the other part...
[43:48.380 --> 43:50.900]  But that's not necessarily going to be enough.
[43:51.380 --> 43:57.040]  Because one of the things with SMTP is, Okay, we've got this store and forward mail protocol.
[43:57.720 --> 44:04.640]  And say you've got a bunch of content, And your content is 2,456k.
[44:06.460 --> 44:07.020]  Okay.
[44:07.540 --> 44:11.200]  And now you've got this SMTP message going across another hop.
[44:11.440 --> 44:13.700]  That is 2,456k.
[44:14.080 --> 44:15.500]  Well, if you've got...
[44:15.500 --> 44:28.260]  If you're up against a strong adversary That has your global vision into your network, They can pretty soon work out that this message going on this link Was this message going on this link.
[44:29.120 --> 44:33.600]  Now, at that point, yes, That is a fascinating problem to solve.
[44:33.920 --> 44:36.260]  And that is what I...
[44:37.720 --> 44:43.060]  I think I've got a really neat solution to it Until Bruce kind of like rained on my parade.
[44:44.860 --> 44:47.320]  What you need to do there is to replace SMTP.
[44:49.320 --> 44:52.200]  But we do have a mechanism that makes that possible.
[44:52.200 --> 44:57.860]  Because if you think of what a finger is doing, It is a set of descriptions of how you can talk to me.
[44:58.500 --> 45:02.740]  And one of the things that slots in there is you can change the transport.
[45:03.100 --> 45:07.000]  You can say, okay, instead of talking to me on TCP, use Tor.
[45:08.240 --> 45:13.420]  Instead of talking to me using SMTP, use this next generation messaging protocol.
[45:14.860 --> 45:22.360]  And so there are hooks in there that allow people to hook in really fascinating stuff.
[45:22.780 --> 45:25.080]  But that's the dessert that I want to get to.
[45:25.160 --> 45:26.520]  And I'm not allowed to eat dessert yet.
[45:27.660 --> 45:29.100]  A couple of questions.
[45:29.480 --> 45:35.580]  One is, it was unclear to me if your solution encrypts metadata like the subject line.
[45:36.940 --> 45:38.500]  Or just the body of the mail.
[45:40.220 --> 45:48.580]  I am told by the SMIME world that it is possible to encrypt subject lines in SMIME.
[45:49.860 --> 45:52.780]  However, I have not tested that personally.
[45:53.200 --> 45:57.260]  Until I have tested it personally, I don't trust them.
[45:57.260 --> 46:02.600]  I mean, like, to me, not encrypting the subject line was crazy.
[46:03.200 --> 46:07.720]  I mean, you know, I told them that it was stupid back in 1995.
[46:08.600 --> 46:10.400]  You know, it's just stupid.
[46:12.200 --> 46:18.060]  And basically what you do is you take an RFC 822 message and you just wrap it.
[46:18.300 --> 46:19.540]  Wrap the whole message.
[46:20.120 --> 46:23.880]  Now the problem there is you're still leaking information.
[46:24.460 --> 46:28.760]  And the problem... I mean, the thing about PRISM was it wasn't so much the subject line.
[46:29.460 --> 46:31.960]  It was the from and to addresses.
[46:32.320 --> 46:34.500]  And those leak a lot of information.
[46:34.800 --> 46:42.980]  And those are the pieces that if you want to swap them out, you basically have to think about changing out SMTP.
[46:43.920 --> 46:50.820]  Yes, there are... I've seen people who have come to me with things like, Oh yes, I can do it within SMTP.
[46:50.820 --> 46:54.120]  Yeah, but you know, you've changed the sending client.
[46:54.380 --> 46:56.440]  You've changed the receiving server.
[46:57.660 --> 47:01.780]  Why not just go to something new and modern like JSON, you know?
[47:02.240 --> 47:02.760]  So, yes.
[47:03.420 --> 47:14.740]  So, the other thing that you might mention is why, aside from religious reliance on the end-to-end principle, you don't think StartTLS helps very much.
[47:15.000 --> 47:15.300]  Oh.
[47:16.900 --> 47:18.340]  Start... Well...
[47:18.340 --> 47:20.520]  You might say what it is because some people might not know.
[47:20.820 --> 47:21.080]  Okay.
[47:21.220 --> 47:27.800]  So, StartTLS is an encryption mechanism that takes place at the SMTP level.
[47:28.500 --> 47:31.700]  And it's a really great security solution.
[47:31.700 --> 47:35.540]  And it's one that everybody should have deployed on the mail server.
[47:35.540 --> 47:37.420]  And, you know, it's one that Komodo sells.
[47:38.460 --> 47:45.060]  The problem with it is that when your message is going across the Internet, it's going through at least three hops.
[47:45.480 --> 47:58.200]  First of all, your message is going to go from your mail client to your outbound mail server using what is sometimes called the submit protocol, but is actually just SMTP over a separate port.
[47:58.200 --> 48:06.960]  From there, it goes from the outbound mail server across the Internet to the inbound mail server of the destination.
[48:07.320 --> 48:11.000]  And that's the hop that is generally secured with TLS.
[48:11.460 --> 48:15.580]  And then, finally, the receiver is probably going to download it using POP or IMAP.
[48:16.080 --> 48:23.980]  Now, if you want to have the mail encrypted, you've got to have all three of those pieces have to be encrypted.
[48:24.220 --> 48:25.120]  Number one.
[48:25.120 --> 48:26.900]  Number two.
[48:27.220 --> 48:44.020]  If the data is going to sit on a mail server inside Google's infrastructure, say, then all the communication lines that is communicated across inside Google also have to be secured.
[48:44.200 --> 48:51.940]  Otherwise, we get back to the infamous NSA slide, SSL applied and removed here.
[48:54.220 --> 48:57.560]  So, it is a very important security control.
[48:57.980 --> 49:03.400]  And at the moment, that's the only standard-based control that is going to protect your metadata.
[49:04.520 --> 49:09.960]  But unfortunately, it's not going to give you end-to-end encryption of your content.
[49:10.920 --> 49:18.920]  And one of the things that, you know, back in the 1990s, we used to have these debates over where should you do encryption?
[49:19.760 --> 49:24.100]  Should you do it at the message layer or should you do it at the transport layer?
[49:24.820 --> 49:28.360]  And now we know the answer to that is AND.
[49:30.240 --> 49:36.640]  You want to encrypt every message at the message layer and the transport layer.
[49:36.880 --> 49:40.340]  Message layer security is not a substitute for transport layer security.
[49:40.560 --> 49:43.680]  Transport layer security is not a substitute for message layer security.
[49:48.470 --> 49:56.170]  How do you see this working with web-based email like Gmail, especially since features like search require them to have access to the plain text?
[49:56.530 --> 49:57.350]  Okay, yeah.
[49:57.470 --> 50:04.290]  This is actually one I get asked a lot because I was recently involved in a court case involving webmail.
[50:04.830 --> 50:11.230]  It was one of the... I spend a lot of my time working as an expert witness in patent cases.
[50:11.450 --> 50:17.630]  And the reason for that is that I don't have a choice in being a witness in these cases.
[50:18.070 --> 50:20.790]  I only have a choice as to whether I get paid or not.
[50:21.310 --> 50:29.930]  And when you're sitting around a room and there are eight people in the room and you're the only person who's not getting paid, it kind of sucks.
[50:31.030 --> 50:40.190]  And one of the things that... this was a case involving a claim on webmail and the party claimed to have invented it.
[50:40.270 --> 50:44.090]  And I came out and said, well, no, I had webmail running first.
[50:44.370 --> 50:54.350]  And I can prove that I did it before then because I had to go over to Tim and fix the HTB protocol because the post command didn't work at the time.
[50:56.410 --> 51:02.010]  So, you know, I invented webmail if that's kind of something to boast about.
[51:02.490 --> 51:02.570]  Yeah.
[51:03.370 --> 51:03.830]  Yes.
[51:04.730 --> 51:09.330]  Doing webmail is an important thing that we've got to get done for a whole system.
[51:11.450 --> 51:13.450]  There's a couple of ways that you could do it.
[51:13.590 --> 51:23.570]  The best way for me, as far as I'm concerned, would be to have an HTML widget which would be secure editing environment where people would kind of like edit their email.
[51:23.930 --> 51:29.830]  And then that would dump out an encrypted block that then... that was visible by JavaScript.
[51:30.250 --> 51:34.390]  And then that could be processed just as a normal webmail data item.
[51:35.510 --> 51:42.790]  There is a team at Google who are working... they've got PGP working inside Gmail.
[51:43.570 --> 51:46.430]  I've not had a chance to sit down and talk to them.
[51:46.630 --> 51:49.830]  I will be talking with them next week.
[51:50.590 --> 51:53.530]  I'm going straight from this conference to Toronto to the ITF.
[51:53.690 --> 51:56.870]  And I've got some time booked out with Ben Lurie to talk about it.
[51:56.930 --> 51:58.330]  So, I believe it's possible.
[51:59.050 --> 52:00.470]  Just haven't had time to do it.
[52:01.270 --> 52:01.770]  Yes.
[52:01.970 --> 52:05.730]  I'm curious about the certificate or the descriptions you're posting.
[52:05.970 --> 52:07.330]  You said to any web server.
[52:07.470 --> 52:08.630]  How do you authenticate that?
[52:08.750 --> 52:14.410]  And how would you keep someone from doing what you described with the spam filter?
[52:14.930 --> 52:22.070]  Unzipping it, taking a look, zipping it up to the actual... Uh... Sorry, I didn't catch that.
[52:22.750 --> 52:28.730]  You said the description of... of the message gets posted on any web server.
[52:28.830 --> 52:29.870]  It just needs to be posted anywhere.
[52:30.170 --> 52:30.590]  Oh, okay.
[52:30.750 --> 52:39.450]  So, the reason that the finger doesn't need to be encrypted or whatever is because all the data that the end party is going to rely on is signed data.
[52:40.010 --> 52:43.410]  So, you don't just stick your key onto... the finger isn't just the key.
[52:43.690 --> 52:49.410]  It is the master key which is validated by the finger, by the fingerprint.
[52:50.150 --> 52:53.470]  The master key then signs the online key.
[52:54.010 --> 52:56.290]  The online key then sends...
[52:56.290 --> 52:57.470]  signs the end entity keys.
[52:57.710 --> 53:05.310]  So, all the data that you're relying on has a trust path that goes back up to the... the fingerprint.
[53:05.710 --> 53:08.810]  And that's what you started with as your axiom of trust.
[53:09.090 --> 53:17.510]  And then the problem of developing alternative trust models simply becomes the problem of mapping any email address to a fingerprint.
[53:18.030 --> 53:20.630]  And if you've got that, then you can do all sorts of interesting things.
[53:20.850 --> 53:22.470]  Anyway, I think I'm out of time now.
[53:22.770 --> 53:24.710]  Thank you very much for listening.
[53:25.070 --> 53:31.230]  And, you know, anybody interested in doing this stuff, there's a sign out button on my website, prisonproof.org.
[53:31.310 --> 53:31.910]  Thank you very much.
[53:31.910 --> 53:33.710]  Thank you
[53:45.010 --> 53:46.950]  very much.