[00:29.540 --> 00:36.020] Just a reminder to everybody, if you weren't able to get into another presentation, we will have them all on DVD out in the lobby here starting tomorrow. [01:49.540 --> 01:51.060] My name is Daniel Kahn Gillmor. [01:51.640 --> 01:52.860] I work with the ACLU. [01:52.940 --> 01:54.360] I'm a technologist for the ACLU. [01:54.480 --> 02:05.900] My interests are in privacy and civil liberties and how the technology that we work on and that's part of our lives is related to that. [02:06.060 --> 02:18.560] So this is a talk about the relationship between privacy and confidentiality and how in many situations we find ourselves trading off our privacy for confidentiality and why that may not be a good idea and what we can do about it. [02:20.220 --> 02:22.580] So yeah, I want to go ahead and just get started here. [02:24.580 --> 02:28.580] So we live in a sort of surveillance bonanza times here, right? [02:28.740 --> 02:34.240] So this right now is massively more communication going on on networks than ever before. [02:35.320 --> 02:40.460] You've probably seen that the NSA folks call this the golden age of SIGINT in this document that they have. [02:42.080 --> 02:47.360] And so there's all this opportunity for surveillance and I think that's a problem. [02:47.740 --> 02:49.880] So why is that a problem? [02:49.980 --> 02:52.420] I think it's worth just sort of framing it and making sure that it's clear. [02:52.680 --> 02:55.140] Why do we object to surveillance in the first place? [02:55.400 --> 02:58.300] So people will tell you that it's creepy and it's creepy. [02:58.500 --> 03:03.880] People will tell you that there's inherent human dignity and that we have human rights to privacy and I would agree with those things too. [03:04.280 --> 03:06.840] But I think those are not sufficient arguments. [03:07.300 --> 03:13.460] Maybe they're sufficient, but I think there are still more arguments that we can make for why surveillance is a real problem. [03:13.660 --> 03:20.440] And in particular, it's worth remembering that surveillance is a tool for social control and a tool for power. [03:20.440 --> 03:23.580] And you don't have to believe me that it's a tool for power. [03:23.940 --> 03:30.400] This logo here is the logo of the Office of Information Awareness, which they cancelled, but they did all the programs anyway. [03:30.680 --> 03:33.440] And it says here their little motto is knowledge is power. [03:33.720 --> 03:36.160] And we've got the all-seeing eye creepily peering over the globe. [03:36.480 --> 03:41.740] So when I'm talking about anti-surveillance stuff, I'm doing it because I'm concerned about social control and power. [03:41.920 --> 03:44.600] I'm also concerned about the creepiness and the human rights issues. [03:45.120 --> 03:48.320] But I think it's worth focusing on the power and what can we do about it. [03:49.340 --> 03:54.520] So the folks who like to do surveillance like to break it out into two broad categories, right? [03:54.580 --> 03:56.920] They say, well, there's content and then there's metadata. [03:57.560 --> 03:59.420] So I want to sort of explore that a little bit. [04:01.720 --> 04:10.960] So content is the usual things that you might think of with somebody with the headphones on listening to the conversation or reading your webpage traffic as it goes by. [04:11.180 --> 04:13.040] You know, it's what are you saying? [04:14.120 --> 04:16.220] It's what kind of plans do you have? [04:16.520 --> 04:19.300] It's, you know, what's in your diary if you're writing your diary? [04:19.560 --> 04:21.100] That's like, that's all the content stuff. [04:22.120 --> 04:25.640] But metadata is almost everything else. [04:25.780 --> 04:28.100] So it's all kinds of little details, right? [04:28.100 --> 04:30.540] Like, when do you talk? [04:30.660 --> 04:31.640] Who are you talking to? [04:32.340 --> 04:33.640] From where are you talking? [04:34.160 --> 04:36.280] Like, what time did you write in your diary? [04:36.380 --> 04:38.400] Not what did you write, but what time did you write? [04:38.480 --> 04:41.520] And how long was the thing that you wrote in the diary? [04:41.720 --> 04:48.660] So there's all of these different pieces of information that are not content that still give you some information. [04:49.500 --> 04:53.400] And so I wanted to just point out here with this diagram here. [04:53.480 --> 04:56.000] This diagram is, this is a great visualization. [04:56.620 --> 05:02.320] I can give you a pointer to it if you want it later, of philosophers, right? [05:02.440 --> 05:06.440] So the different philosophers who worked with each other or cited each other are linked to each other. [05:06.540 --> 05:13.900] And you can tell just from the linkages, who they worked with and when they worked with it, how often they worked with, you can tell which ones are the really important philosophers. [05:14.600 --> 05:20.180] And I want to point out here that, you know, you've got Kant and you've got Marx and you've got Hegel. [05:20.440 --> 05:23.600] And those folks show up as centralized nodes here. [05:23.740 --> 05:28.000] And you can figure that out even without understanding any of the philosophy involved. [05:28.320 --> 05:31.900] The philosophy is the content, the relationships here are the metadata. [05:33.540 --> 05:41.740] So if we want to oppose surveillance, generally with communications on networks today, we're going to use some kinds of crypto. [05:41.740 --> 05:46.180] And we want to use crypto that supports, that provides confidentiality and privacy. [05:46.440 --> 05:49.600] So confidentiality is when you're protecting your content. [05:49.960 --> 05:53.280] And privacy is roughly when you're protecting your metadata. [05:53.280 --> 05:57.560] Now, there's also other terms people will use that you'll hear. [05:57.760 --> 06:01.280] I'm using the terms confidentiality and privacy in this form here. [06:03.040 --> 06:07.540] And these things are relevant, confidentiality and privacy, in protocol design. [06:07.700 --> 06:10.100] If you're designing how the actual communications work. [06:10.300 --> 06:12.480] In software configurations. [06:14.380 --> 06:15.800] In user interface. [06:16.000 --> 06:19.740] All of these things are places where we need to be thinking about confidentiality and privacy. [06:20.420 --> 06:22.820] So, still on the sort of social level. [06:23.340 --> 06:27.980] Which do you think has more value to someone who wants to use surveillance for social control? [06:29.040 --> 06:30.620] Content or metadata? [06:31.580 --> 06:35.840] So, I would argue that content is actually... [06:35.840 --> 06:38.640] The interpretation of content is sort of a fuzzy thing. [06:38.760 --> 06:40.040] And it can be a difficult task. [06:40.200 --> 06:41.720] It can require humans to... [06:41.720 --> 06:47.440] Whereas metadata is sort of automatically in these discrete machine parsable chunks. [06:47.440 --> 06:50.720] So, you can get metadata and you can process it at scale. [06:50.720 --> 06:51.640] If you're a big... [06:51.640 --> 06:54.320] If you're a big surveillance engine who's interested in social control. [06:54.640 --> 06:55.600] So, on the one hand... [06:56.520 --> 07:00.240] Yes, you can do some machine learning that kind of understands the human content. [07:00.920 --> 07:04.700] But really, all of the metadata, you can do these automated analyses really fast. [07:04.980 --> 07:08.460] Imagine trying to write something to understand the content of all of those philosophers. [07:08.860 --> 07:11.380] As opposed to just understanding the relationships between them. [07:11.420 --> 07:12.780] Which you can quantify discreetly. [07:13.280 --> 07:17.040] So, what does metadata at scale give you if you're a surveillance regime? [07:17.420 --> 07:19.800] Well, who's the linchpin of the social graph, right? [07:19.860 --> 07:23.180] Oh, we know that this Marx guy seems to have influenced a lot of philosophers. [07:24.460 --> 07:28.640] If you decide one particular person is a bad guy, you can figure out who's related to them. [07:28.800 --> 07:30.560] And generate some new targets for yourself. [07:30.960 --> 07:34.340] You can figure out who's been in a certain place at a certain time. [07:34.620 --> 07:37.820] This image here is a photograph from the New York Times of a protester... [07:37.820 --> 07:40.680] Of someone's cell phone in Kiev. [07:41.880 --> 07:45.850] They got everybody who was at this one place got a text message that says... [07:46.520 --> 07:52.380] I believe the Times translates it as, Dear subscriber, you are registered as a participant in a mass disturbance. [07:53.640 --> 07:54.140] Right? [07:54.560 --> 07:57.860] So that's... there's no content evaluation there at all. [07:57.980 --> 07:58.980] This is all just metadata. [07:59.360 --> 08:02.240] And there's also very interesting patterns you can pull from metadata. [08:02.380 --> 08:04.700] And I recommend these papers that I'm pointing to up here. [08:04.700 --> 08:09.640] There's a metaphone from the Stanford security labs where they had people install an app... [08:09.640 --> 08:12.520] That sent all of their telephony metadata to Stanford... [08:12.520 --> 08:15.580] Rather than just to the cell phone providers and the government. [08:16.220 --> 08:19.280] And then Stanford combed through it to try to figure out what you could get from it. [08:19.340 --> 08:20.420] Very sensitive stuff in there. [08:20.880 --> 08:23.560] And then I know why you went to the clinic is this paper about... [08:23.560 --> 08:26.760] Looking at the traffic analysis of HTTPS. [08:26.860 --> 08:29.840] You can figure out what web page people are going to... [08:30.460 --> 08:31.700] Without even knowing... [08:32.560 --> 08:33.860] Without being able to see the content. [08:33.860 --> 08:37.020] You can figure out what web page they went to just by looking at the traffic analysis. [08:37.240 --> 08:39.220] How big was the data that was sent? [08:39.740 --> 08:42.040] What were the patterns of data requests that happened? [08:43.100 --> 08:43.500] So... [08:43.500 --> 08:45.580] So what kind of things do we want to protect? [08:45.900 --> 08:46.120] Right? [08:47.060 --> 08:50.640] What kind of things are the surveillance regimes actually spying on? [08:50.840 --> 08:54.860] Well, some of the folks who operate surveillance regimes will tell us that... [08:56.460 --> 08:59.040] Sorry, I'm kind of leaning here for the pointer. [08:59.440 --> 09:00.280] I don't know how to get this... [09:00.280 --> 09:00.660] There we go. [09:02.000 --> 09:04.240] Nobody is listening to your telephone calls. [09:07.120 --> 09:09.000] That's not what this program is about. [09:09.840 --> 09:10.200] So... [09:10.200 --> 09:10.780] So... [09:10.780 --> 09:12.200] You might not believe that guy. [09:13.460 --> 09:18.720] But he's telling you that they're not actually doing this content work. [09:19.360 --> 09:19.920] So... [09:19.920 --> 09:20.580] What are the... [09:20.580 --> 09:21.320] What are the same... [09:21.320 --> 09:23.180] I think you all recognize who that was. [09:23.780 --> 09:26.400] What are the guys who operate these systems... [09:26.400 --> 09:27.400] What else do they say? [09:27.400 --> 09:27.420] Okay. [09:28.520 --> 09:29.100] So... [09:29.100 --> 09:30.140] Let me just... [09:30.140 --> 09:38.240] First of all, David's description of what you can do with metadata, quoting a mutual friend, Stuart Baker, is absolutely correct. [09:38.780 --> 09:38.980] Okay? [09:39.300 --> 09:41.040] We kill people based on metadata. [09:42.820 --> 09:43.220] So... [09:43.220 --> 09:47.980] That was General Michael Hayden, who was a big shot at the NSA. [09:49.140 --> 09:49.540] So... [09:49.540 --> 09:50.100] So I think... [09:50.820 --> 09:53.460] You know, Hayden, right after he said that, went on to say, well, but... [09:53.460 --> 09:58.480] But we don't do that with this metadata, referring specifically to the U.S. phone record metadata. [09:58.760 --> 10:02.200] Which I'm sure is very reassuring to all of you who are not U.S. persons. [10:04.820 --> 10:05.220] So... [10:05.220 --> 10:05.880] So... [10:05.880 --> 10:06.280] Okay. [10:07.060 --> 10:07.460] So... [10:07.460 --> 10:10.100] My point here is, we need to be thinking about protecting our metadata. [10:10.280 --> 10:14.000] We need to be thinking about privacy the same way that we're thinking about confidentiality. [10:14.260 --> 10:16.020] Which is that this is an important thing. [10:16.800 --> 10:18.520] Historically, we've done a terrible job. [10:18.740 --> 10:20.780] We've done a terrible job at confidentiality, even. [10:20.920 --> 10:29.280] But in the places where we've tried to protect ourselves from surveillance, most of what we've done has been a protection against violations of confidentiality. [10:29.340 --> 10:30.380] They've been protecting the content. [10:30.380 --> 10:31.740] They have not been protecting metadata. [10:32.800 --> 10:40.620] So, and there are some circumstances where we've even deliberately given up some privacy in order to have a little bit more confidentiality. [10:40.740 --> 10:42.320] So, we need to think about those trade-offs. [10:42.560 --> 10:44.400] So, I'm going to go through a few historical examples. [10:44.640 --> 10:51.320] So, this is one of the common email encryption mechanisms, anti-surveillance mechanisms, right? [10:51.680 --> 10:53.580] We've probably seen an email like this. [10:54.360 --> 10:55.900] This is an encrypted email. [10:56.320 --> 10:59.260] What's visible to someone who sees the email and what's not? [10:59.260 --> 11:04.500] Well, the message body is entirely encrypted, but all of that header stuff is still there. [11:04.720 --> 11:08.940] Who sent it, when they sent it, what the subject is, it's all still visible. [11:09.480 --> 11:11.980] So, confidentiality, no privacy. [11:13.260 --> 11:13.780] Chat. [11:14.720 --> 11:21.780] So, OTR is a very common way that people use to secure their chats if they're using instant messaging of different kinds. [11:23.000 --> 11:31.700] OTR doesn't actually do any kind of protection about who is doing the chatting because it's wrapped inside the protocols that the chat happens at. [11:31.820 --> 11:38.300] So, if you have access to the servers that the chat are happening over, you can still just log all of the packets and see who's talking. [11:38.540 --> 11:43.900] This is a little view of a packet capture from an IRC communication. [11:44.100 --> 11:48.440] You can see there's a DKG there and there's an Alice there, me talking to Alice. [11:48.440 --> 11:49.860] And yeah, it's all encrypted. [11:50.040 --> 11:56.500] You can see that big scary OTR blob, but the privacy's not so protected. [11:56.820 --> 11:57.880] So, what about the web? [11:57.980 --> 11:59.060] You visit a secure website. [11:59.300 --> 12:00.300] That's got to protect you, right? [12:00.460 --> 12:09.580] So, that's going to protect your confidentiality because you don't want people to see, say, the bank information that's flying back and forth, but it's not going to protect the privacy of the communication. [12:09.580 --> 12:15.580] Because secure websites is HTTPS, which is just HTTP wrapped inside transport layer security. [12:15.880 --> 12:21.440] So, transport layer security sets up this encrypted tunnel and it starts with a handshake. [12:21.660 --> 12:23.240] And the handshake looks like this up here. [12:23.480 --> 12:30.380] The key thing to note about this handshake is that the items with the curly brackets around them are the encrypted part. [12:31.380 --> 12:33.620] All of the rest of the handshake is in the clear. [12:33.620 --> 12:38.720] This is the latest, this is the current version of transport layer security, TLS 1.2, leading edge. [12:41.240 --> 12:49.680] All of the client hello, server hello, certificates, key exchanges, certificate verify information, all of that stuff is in the clear. [12:50.860 --> 12:54.060] So, we're not doing a good job at protecting the metadata. [12:54.500 --> 12:59.660] We're not supporting people in there who want to have private communications very well. [13:00.340 --> 13:01.620] Why is it so hard? [13:02.320 --> 13:04.880] This dog is up here because thinking about this makes me a little tired. [13:07.640 --> 13:13.300] It's hard for a bunch of reasons, but I've got, I've sort of outlined four, and I want to go through those four in more detail in a little bit. [13:13.380 --> 13:15.020] But I'm just going to run through the four right now. [13:15.280 --> 13:19.740] So, it's hard because some of it is just straight up expensive, and people don't like spending the expense. [13:19.920 --> 13:20.660] They don't like the cost. [13:22.220 --> 13:25.960] It's hard because for communications over networks, you need routing. [13:26.220 --> 13:30.940] Routing information, you know, the central nodes across the route, they need to know where to send the message. [13:31.160 --> 13:32.020] So, that's hard to hide. [13:33.100 --> 13:37.020] It turns out that authentication is actually pretty important for confidentiality. [13:37.280 --> 13:47.800] But authentication is sort of very similar to identification, and the privacy issues are, there's, so there's this push and pull between authentication, confidentiality, identification, privacy. [13:48.560 --> 13:50.800] And lastly, there's an issue about stored state. [13:51.000 --> 13:57.420] The most, the more state that your client has about its view of the world, the more fingerprintable that client is. [13:57.740 --> 14:00.000] And fingerprinting leads to erosions of privacy. [14:00.360 --> 14:01.980] So, let's go into these in a little bit more detail. [14:03.860 --> 14:06.660] So, I said some metadata is just straight up expensive. [14:07.000 --> 14:10.200] There's two obvious examples of that, which are size and timing. [14:10.620 --> 14:20.140] I'd mentioned that I know why you went to the clinic study, where they looked at traffic patterns for HTTPS that basically revealed what web pages within a website people were visiting. [14:20.740 --> 14:23.500] So, that was based on the size of the traffic and the timing. [14:23.500 --> 14:26.620] So, the way to protect against that is pretty straightforward. [14:26.960 --> 14:30.040] You pad your traffic, so you can't tell how big the actual traffic is. [14:30.480 --> 14:31.520] That costs bandwidth. [14:31.780 --> 14:33.800] So, you can see on the top, there's a description, right? [14:34.000 --> 14:48.280] If your communications are, if my response to you is going to be either yes, no, or maybe, and I'm going to encrypt them, so you can't tell what they are, but no is two letters long, maybe is five letters long, and yes is three letters long, then it doesn't matter that I've encrypted them, [14:48.440 --> 14:51.860] because anybody looking at the sizes of the traffic can just tell what I just answered. [14:51.860 --> 14:56.320] So, you need to pad everything out to be the same size in your responses, that cost bandwidth. [14:56.880 --> 15:03.060] Message timing, so, in the next line down there, you can see a little call-and-response between the green person and the blue person. [15:03.160 --> 15:05.560] The green person says something, the blue person responds. [15:05.680 --> 15:06.900] It's a timeline going across. [15:09.000 --> 15:12.880] In the first case, you can tell that the blue person didn't have to think very hard about their response. [15:13.460 --> 15:15.260] In the second case, you can tell that they did. [15:15.920 --> 15:24.880] Now, there are some circumstances where it's very useful from a surveillance perspective to know, was that page a 404 or was it an actual content page? [15:24.980 --> 15:26.860] And maybe it takes a while to render a content page. [15:27.260 --> 15:39.020] So, if your 404s are fast, 404 meaning found, not found, and your contentful pages take a little while to generate, then it's pretty easy to tell whether someone just made a failed request or a successful request. [15:39.680 --> 15:44.500] So, the way you fight back against that is you introduce additional delay. [15:45.680 --> 15:47.520] And that costs latency. [15:47.760 --> 15:51.000] Now, all of your web pages load as slow as your slowest web page. [15:51.140 --> 15:52.460] People don't like paying these costs. [15:54.000 --> 15:55.900] So, routing information, right? [15:56.640 --> 16:00.120] Your IP headers leak info, your email messages leak info. [16:00.720 --> 16:09.240] There's lots of ways that the intermediate nodes can get access to who is on either side of the communication. [16:11.240 --> 16:12.860] This is a really hard problem. [16:13.200 --> 16:20.200] Solving it also introduces costs, similar to the costs that are involved in masking these other pieces of metadata. [16:21.220 --> 16:22.940] We have a bunch of work towards it. [16:23.280 --> 16:26.600] You all probably recognize the Tor onion logo there. [16:26.780 --> 16:32.900] Tor is the onion router and it is a way to help you hide what your IP address is. [16:33.080 --> 16:37.180] So, it provides you with a layer of privacy that regular Internet communications won't have. [16:37.440 --> 16:40.760] So, we have some experience and some knowledge deploying these things. [16:40.920 --> 16:42.240] They're not very widely spread. [16:42.440 --> 16:48.120] We need more people working on those and researching them and implementing them and supporting them. [16:48.260 --> 16:53.880] So, this is an important area to focus on. [16:54.540 --> 17:07.360] I also want to mention this idea of rendezvous servers, which there are some new protocols people are starting to experiment with for person-to-person communications that can make it so that the rendezvous server is like a point where two people can check in. [17:08.440 --> 17:16.920] And it's... the systems have been designed in a way that even the rendezvous server can't tell that it's the same person checking in for multiple check-ins. [17:16.920 --> 17:19.900] So, I could meet Alice today and I could meet Bob tomorrow. [17:20.120 --> 17:23.420] We could use the same rendezvous servers to have our online communications. [17:24.340 --> 17:27.880] And the rendezvous server wouldn't be able to tell that I'm me in both of those communications. [17:28.080 --> 17:32.400] So, those are... these are some interesting areas that are under development these days. [17:32.500 --> 17:34.320] I recommend reading up on Pond. [17:36.020 --> 17:38.220] And there are several others that are using rendezvous servers. [17:38.340 --> 17:40.240] But Pond is an interesting one. [17:41.520 --> 17:42.240] So, okay. [17:42.380 --> 17:46.660] So, we talked about... so, we talked about the expensive metadata. [17:46.920 --> 17:48.360] We talked about routing information. [17:49.040 --> 17:55.160] So, I'm gonna go... this is... now this is a part... authentication is where privacy and confidentiality actually start to come into pretty tight conflict. [17:56.660 --> 18:00.240] So, why is authentication critical for confidentiality? [18:02.200 --> 18:13.340] So, if Alice wants to talk to Bob and she wants her communication to be confidential, then she wants... what that means is she wants only her and Bob to know what she said. [18:14.160 --> 18:23.380] If she doesn't actually know that it's Bob, then regardless of the layers and layers of crypto that she puts on top, if she doesn't know that she's talking to Bob, she could be talking to anybody. [18:23.560 --> 18:26.500] So, she doesn't actually have the confidentiality guarantees that she wants. [18:27.420 --> 18:34.120] So, you could have one party in a communication be anonymous and the other party be willing to talk to anonymous people over a secure channel. [18:34.660 --> 18:40.220] But you need at least one of the parties to It could be anonymous or else the confidentiality guarantee doesn't really mean much. [18:42.460 --> 18:47.660] So I'm going to give some examples here about where authentication comes into conflict. [18:47.860 --> 18:50.320] So one of them is server name indication. [18:50.600 --> 18:52.180] So this is in transport layer security. [18:52.280 --> 18:58.140] Again, this is the encrypted tunnel that's used for HTTPS and used in many other places as well. [18:58.340 --> 19:02.700] So the client connects to the server and starts that TLS handshake, which we saw was in the clear. [19:04.700 --> 19:08.640] Well, one nice thing today is that we can run multiple services on a single IP address. [19:08.820 --> 19:16.220] So all the routing information that we were just talking about is kind of masked because you could be running 10 services or 100 services on this one IP address in one port. [19:17.100 --> 19:18.180] So that's nice. [19:18.620 --> 19:26.900] But it turns out that for the client, the client will connect and say in the TLS handshake, hey, by the way, here's the name of the service that I'm looking for. [19:27.340 --> 19:29.460] So what you see here is a packet capture. [19:30.600 --> 19:35.180] And that's a packet capture of me going to look at Jake Applebaum's GitHub page. [19:35.320 --> 19:37.700] I'm interested to see what kind of stuff is Jake doing. [19:38.280 --> 19:50.560] So despite the fact that it's HTTPS, my web browser has actually sent the string ioerror.github.io in the clear as part of the TLS handshake. [19:50.560 --> 19:57.840] So I need to tell the server that because the server needs to know how to respond to me. [20:00.540 --> 20:09.240] But I'm sending it in the clear, which means that anybody who's observing the network traffic now knows that I was talking to GitHub about Jake's files. [20:09.240 --> 20:13.700] So if Jake is someone of interest, whoop, that just put me on a list someplace. [20:14.580 --> 20:17.360] So you'd like to encrypt the server name indication. [20:17.540 --> 20:22.180] This is called server name indication extension that allows you to have these multiple sites on a single IP address and port. [20:22.460 --> 20:23.860] So you'd like to encrypt that. [20:24.700 --> 20:26.220] But it's real hard to do. [20:26.940 --> 20:29.820] It's hard to do because of this chicken and egg problem, right? [20:30.300 --> 20:35.040] In order for the server to identify itself to me, it needs to send me a certificate. [20:35.640 --> 20:36.960] Well, okay. [20:37.380 --> 20:38.200] So it can send me... [20:38.200 --> 20:39.920] How does it know which certificate to send? [20:40.080 --> 20:46.360] Let's say that the GitHub servers offer both ioerror.github.io and your... [20:47.940 --> 20:52.400] Let's see, the CIA's own GitHub repository. [20:52.660 --> 20:54.240] I don't know if the CIA has a GitHub repository. [20:55.120 --> 20:58.980] So I don't want anybody who's observing the network to know which of these things I'm looking at. [20:58.980 --> 21:06.780] So I need to tell the server I'm looking for one of them so that the server knows how to identify itself to me, right? [21:06.860 --> 21:12.480] It could identify itself as ioerror.github.io or it could identify itself as CIA.github.io. [21:12.700 --> 21:16.980] I apologize if anybody here has the CIA handle on GitHub and I'm maligning you right now. [21:18.460 --> 21:26.660] So there's this problem where they'd have to send a certificate and I'd have to validate their certificate because confidentiality requires authentication. [21:26.660 --> 21:33.560] I'm gonna validate the certificate before I go ahead and am sure that it's the right place, before I start sending encrypted data. [21:33.780 --> 21:44.260] So if I was to encrypt the connection to send the string that tells it what I'm looking for, then I've already missed... then it has to send me some other certificate, right? [21:44.380 --> 21:51.540] So there's this... there's this chicken and egg problem when you're trying to set up the handshake that makes encrypting SNI quite difficult. [21:52.260 --> 21:54.120] We're actually working on this right now. [21:54.900 --> 21:58.960] I'm involved in the Internet Engineering Task Force Transport Layer Security Working Group. [21:59.300 --> 22:05.660] And we're in the process of trying to create a TLS version 1.3 which will encrypt as much of the handshake as possible. [22:05.740 --> 22:07.000] That's one of our explicit goals. [22:07.980 --> 22:12.940] And it... it looks like we will... it may be possible to encrypt SNI. [22:13.080 --> 22:14.600] I'm pushing hard to make sure that we do. [22:14.860 --> 22:19.460] It is gonna cause an additional round trip probably for the communication in many... in many circumstances. [22:22.620 --> 22:24.300] So... so there's some trade-offs there. [22:24.500 --> 22:29.200] But if we don't encrypt it, then we're continuing to leak all this metadata, which is a bad idea. [22:29.760 --> 22:31.560] So that's something that's on the table right now. [22:31.700 --> 22:33.920] If you're interested in that, I'd be happy to talk with you more about it later. [22:34.680 --> 22:42.080] Let me give another example about authentication and where we throw away our privacy for the... [22:42.080 --> 22:43.860] for the sake of getting better confidentiality. [22:44.340 --> 22:48.800] And this is a situation where even if the entire TLS handshake was encrypted, we would be failing. [22:50.240 --> 22:52.980] So OCSP is the Online Certificate Status Protocol. [22:53.580 --> 22:55.640] So the TLS handshake works. [22:56.000 --> 23:00.060] The client says to the server, you know, hey, I want to... I want to connect to foo.example. [23:00.140 --> 23:02.680] The server says back to the client, sure, I'm foo.example. [23:02.680 --> 23:03.520] Here's my certificate. [23:04.020 --> 23:09.320] The client verifies the certificate and then if it's valid, then it goes ahead and has an encrypted connection to the server. [23:10.840 --> 23:12.920] So, what does it mean is the certificate valid? [23:13.440 --> 23:13.640] Right? [23:14.160 --> 23:20.140] Well, it could be that there's someone who's made a fake certificate and you might get tricked. [23:20.320 --> 23:23.340] But another thing that could happen is that the server's key could have been compromised. [23:23.340 --> 23:28.080] So Heartbleed, which was earlier this year, many of you in the audience... [23:28.080 --> 23:31.800] Who in the audience had to deal with Heartbleed on their servers? [23:32.880 --> 23:33.360] Yeah. [23:34.200 --> 23:35.260] That's kind of a drag. [23:35.720 --> 23:36.520] That was a lot of work. [23:38.320 --> 23:43.960] And it was basically... it was a mistake in a very common transport layer security implementation called OpenSSL. [23:44.240 --> 23:48.140] And it could have exposed the secret keys of your servers if you were ever running them. [23:48.140 --> 23:53.100] So the best advice was replace all of the keys on all of your servers and revoke all of the old certificates. [23:53.580 --> 23:54.720] So revocation is important. [23:55.100 --> 23:57.280] If I just get a certificate, I don't know if it's revoked or not. [23:57.320 --> 23:58.140] So how do I tell? [23:58.580 --> 24:09.380] Well, the server has embedded within it an OCSP response field that says, if you want to know if this is revoked or not, you can talk to my OCSP responder over there. [24:11.260 --> 24:14.680] And so I get the certificate and I say, well, I don't know if this has been revoked or not. [24:14.680 --> 24:17.120] This could be somebody's old certificate from pre-heart bleed. [24:17.920 --> 24:20.020] So I guess I better look up whether it's revoked or not. [24:20.120 --> 24:29.200] I'm going to turn around and make it an OCSP request, which is just an HTTP post, to the OCSP responder and say, is this certificate still valid? [24:29.600 --> 24:32.540] Now, I've drawn it here so that it's passing the whole certificate. [24:32.680 --> 24:40.260] It doesn't actually pass the whole certificate, but it passes an identifier that's a unique identifier that's very easy to pin to the certificate that you just saw. [24:41.440 --> 24:44.320] And then the server responds and says, yep, it's still valid or no, no. [24:44.320 --> 24:45.620] That one's already been revoked. [24:46.780 --> 24:59.300] So the point here is that if you want to observe who's visiting a given website and people are actually using this OCSP protocol, all you have to do is sit on the network path to the OCSP server. [25:00.020 --> 25:03.920] You don't even have to be on the network path between the client and the web server. [25:04.060 --> 25:05.560] You can just sit on the OCSP server. [25:05.660 --> 25:08.820] And by the way, the OCSP request and response is in the clear. [25:09.900 --> 25:18.500] And so you can sit on the network at the OCSP server and you can learn every time somebody who's doing OCSP visits this website that you're interested in. [25:18.560 --> 25:25.420] In fact, you can learn it for all of the websites that were certified by the same certificate authority that uses this same OCSP responder. [25:25.900 --> 25:35.060] So this is a total disaster in terms of privacy because your clients are basically reporting themselves to some central authority to say, yeah, I'm visiting that website. [25:35.340 --> 25:41.240] Yeah, I wanted to go to AlcoholicsAnonymous.org via HTTPS with my secure session. [25:41.660 --> 25:43.360] I'm going to tell it over there in the clear. [25:45.520 --> 25:47.220] So, yeah, that's a problem. [25:47.800 --> 25:48.880] You can improve that. [25:48.880 --> 25:59.680] There's a mechanism called OCSP stapling where the server itself fetches the OCSP response from the OCSP responder and keeps a cache of up-to-date OCSP responses. [25:59.840 --> 26:02.820] And then it sends the OCSP response in the communication to the client. [26:02.920 --> 26:05.300] So the client never has to communicate with the server. [26:06.060 --> 26:07.120] That's a good step. [26:07.260 --> 26:08.680] And it's a step in the right direction. [26:08.680 --> 26:10.920] But for a number of reasons, it doesn't solve the whole problem. [26:11.160 --> 26:13.520] OCSP is also kind of broken, period. [26:13.800 --> 26:15.480] Like it doesn't actually work for revocation either. [26:16.120 --> 26:22.020] But yes, so this is a thing where people try to use it to improve their confidentiality and they end up actually making their privacy much worse. [26:22.420 --> 26:24.160] So one more authentication example. [26:24.800 --> 26:25.700] OpenPGP key servers. [26:25.840 --> 26:27.460] Who here has an OpenPGP key? [26:29.460 --> 26:30.020] All right. [26:30.120 --> 26:32.160] It's like a quarter of the audience, maybe. [26:33.920 --> 26:37.720] So people have an OpenPGP key, they've uploaded their key to the public key servers. [26:37.740 --> 26:38.420] I have. [26:38.520 --> 26:39.340] I've uploaded my key. [26:39.500 --> 26:40.400] Why did I upload it? [26:42.180 --> 26:45.320] I upload it so people can send me confidential messages, right? [26:45.480 --> 26:49.080] They can find my key on the key servers and then they can encrypt messages to my key. [26:49.540 --> 26:50.420] So that's great. [26:50.700 --> 26:53.500] But what I've done is I've exposed myself on the public key servers. [26:53.720 --> 26:56.220] I've said, hey, I'm somebody who has one of these keys. [26:56.340 --> 26:57.300] You might be interested in me. [26:58.960 --> 27:00.360] I actually think that's a good trade-off. [27:00.480 --> 27:02.280] I've decided deliberately to make that trade-off. [27:02.620 --> 27:04.560] But you also upload your certifications. [27:04.900 --> 27:10.520] So when you sign keys with somebody in OpenPGP, you're saying, I believe this key connects to this person. [27:12.460 --> 27:14.720] And those certifications you also upload. [27:14.880 --> 27:16.940] And I've uploaded many certifications of my own. [27:17.540 --> 27:18.900] In fact, you can see one up here. [27:19.000 --> 27:19.840] There's a little example here. [27:19.920 --> 27:23.280] One of my colleagues, his key is on the public key servers. [27:23.300 --> 27:26.780] And if you look at it, you can see that I've certified it. [27:28.040 --> 27:31.800] So that visibility creates a linkage between the two people. [27:32.080 --> 27:34.720] And again, back to the philosophy thing, right? [27:34.880 --> 27:35.820] Now there's this linkage. [27:35.880 --> 27:36.980] Now you can get a little graph. [27:37.360 --> 27:41.900] The picture here is a graph of a handful of keys and who has certified which keys. [27:42.800 --> 27:48.600] So you can see that some keys are sort of more central to the communications process. [27:48.600 --> 27:51.080] So there's that question of who's the linchpin in this community. [27:51.580 --> 27:56.200] Some of that information is kind of revealed by the key servers and the certifications that are on them. [27:56.820 --> 28:00.020] Not as much, probably, as the philosophy situation was. [28:00.120 --> 28:03.320] Because all people are doing is saying, I believe this person holds this key. [28:04.260 --> 28:11.140] But it does provide some level of graphing to say at least, probably, that these people have met each other in person. [28:11.140 --> 28:18.120] Which maybe you don't want to reveal if you've been talking to, say, an important national whistleblower. [28:18.280 --> 28:19.620] You might not want to reveal that. [28:19.720 --> 28:22.360] So you might not want to have a key signing with that person that's public. [28:23.100 --> 28:32.600] So there are actually mechanisms in the OpenPGP protocol in the specification for providing private certifications and for transmitting private certifications. [28:32.720 --> 28:35.120] But the user interface for this stuff is terrible. [28:35.900 --> 28:45.520] And so I want to emphasize that while some of these things, some of these fixes are fixes that we need to do in the protocols, some of them are fixes that we need to do in the software and at the user interface and user experience layer. [28:45.860 --> 28:53.740] So no matter what part of the stack you're interested in, if you're interested in making tools and working on stuff like this, you can work on it at all different levels. [28:53.980 --> 29:00.600] I tend to focus on the protocol level, but we desperately need people who work on the user interface and user experience as well. [29:03.260 --> 29:05.240] So, okay, so that was authentication. [29:05.700 --> 29:09.100] So there's one, there's this fourth issue here, which is stored state. [29:09.760 --> 29:15.560] And so I want to talk a little bit about how stored state leads to fingerprinting. [29:17.940 --> 29:20.740] So what do I mean when I mean stored state? [29:21.140 --> 29:29.280] If you've got a tool and it's keeping track of the things that it's seen, that keeping track is sort of building its own little internal model of the world. [29:29.500 --> 29:36.080] And I argue that that model of the world is probably different from any other thing that's interacting with the world because it's seen different stuff. [29:36.580 --> 29:42.200] And the more that you act on that stored state, the more your activity is fundamentally fingerprintable. [29:42.380 --> 29:45.720] So some examples of stored state are what's in your web browser cache. [29:46.240 --> 29:51.000] If you use SSH, what keys are in your known hosts file. [29:51.800 --> 29:53.700] The cookies that your web browser holds. [29:53.880 --> 29:58.160] If you use OpenPGP, what keys are in your key ring, who's in your address book. [29:58.320 --> 30:03.760] There's this whole set of things that reflect your view of the world that probably are unique to you. [30:05.200 --> 30:08.560] So, yeah, [30:11.820 --> 30:15.540] so George mentions that you could hash the known hosts in your SSH config file. [30:16.000 --> 30:27.700] So hashing the known hosts, this is a proposal that basically says, well, in your known host file, instead of saying, I visited foo.example, it'll say, I visited arbitrary string that you can't make sense of. [30:28.180 --> 30:38.820] But then the next time you go to foo.example, your tools check your known host file and say, well, we'll take the string foo.example, we'll hash it, we'll, oh, look, it matches that same arbitrary string. [30:39.180 --> 30:42.160] So that's a defense against somebody who steals your known host file. [30:42.520 --> 30:46.460] But it's not a defense against the actionable fingerprinting, right? [30:46.600 --> 30:54.000] So when I say that your stored state is, if that actionable storage state is fingerprintable, the fact is you already have it in your keyring. [30:54.980 --> 30:58.940] And so you're going to behave differently than if you didn't already have it in your keyring, right? [30:59.040 --> 31:03.640] Like your connections are going to happen faster because you know the key of the remote server, you don't have to accept it or not. [31:04.200 --> 31:07.800] And so the fact that it's been hashed doesn't mean that your behavior is any different. [31:07.940 --> 31:13.680] And so if people are fingerprinting by behavior, then the hashing doesn't protect against that. [31:13.860 --> 31:16.180] But it does protect against people who steal the file. [31:17.780 --> 31:19.240] So here's another example. [31:19.460 --> 31:22.340] This is, again, an example from transport layer security. [31:24.020 --> 31:25.940] Transport layer security is expensive, right? [31:26.080 --> 31:30.300] That extra handshake is on top of the actual communications that you'd like to have. [31:30.400 --> 31:32.160] And you go to visit a website, you just want to get the data. [31:32.500 --> 31:39.140] Why do the two round trip handshake to the server in order to start the communication to ask for the data and then finally get it? [31:39.340 --> 31:42.820] Each of those round trips requires packets to go maybe halfway around the world. [31:43.520 --> 31:44.680] So we want to make it faster. [31:44.880 --> 31:45.860] How do we make it faster? [31:46.180 --> 31:48.400] You know, if we make it faster, more people will use it. [31:48.560 --> 31:51.840] We'll increase confidentiality because more people will use a faster protocol. [31:52.020 --> 31:54.480] So you make it faster by reducing the number of round trips. [31:55.160 --> 32:02.180] Well, currently in transport layer security 1.2, the way you reduce the number of round trips is one of the ways is that you can have a session ID. [32:02.400 --> 32:04.820] So the first communication takes two round trips. [32:06.000 --> 32:12.920] But the second communication, because the first communication established a session ID, the second communication can do this resumption. [32:12.920 --> 32:16.560] Where you say, hey, I already had a session with you, let's have another session. [32:17.960 --> 32:22.880] And so you can see there's fewer round trips, there's fewer things exchanged in the clear, which is nice. [32:24.500 --> 32:26.060] But what are the consequences here? [32:26.660 --> 32:28.860] Here's how the session IDs are transmitted. [32:29.120 --> 32:35.320] The client says to the server, I want a session ID so that I can make future connections with you more rapid. [32:35.560 --> 32:40.600] The server says, no problem, I'm going to generate a session ID, I'll store it on my side, and I'm going to send it to you. [32:40.600 --> 32:43.060] This is all in the handshake, which is in the clear. [32:44.320 --> 32:54.720] And then on the resumed connection, right, this two handshake, sorry, one round trip resumed connection, the client says, hey, I'm connecting, and by the way, I'm resuming that session. [32:55.220 --> 32:56.620] Exact same unique string. [32:56.840 --> 32:59.280] And the server says, no problem, we're going ahead with that session. [33:00.100 --> 33:02.120] Again, in the handshake, in the clear. [33:02.780 --> 33:12.400] So what happens, someone who's monitoring the connection can now know not just what website you're visiting, but now they know that you're the same client that visited earlier. [33:12.940 --> 33:16.740] So you've got your laptop in the cafe, you do some work, you go to some website. [33:17.820 --> 33:26.720] Someone who's monitoring that website, you put your laptop to sleep, you go home, you open it up, you go, you're at home, you go to the same website, the same session ID is sent. [33:27.140 --> 33:31.340] Somebody can now link those two communications because of the session ID. [33:32.020 --> 33:37.420] So session ID seemed like a good thing because we were protecting more things because the handshake was faster. [33:37.560 --> 33:38.400] We improved the latency. [33:38.680 --> 33:44.240] But in fact, what we ended up doing was decreasing the privacy because people are now trackable across the cafe to home. [33:47.140 --> 33:48.420] So here's another one. [33:48.520 --> 33:49.760] This one's a little bit more complicated. [33:51.520 --> 33:54.300] But this is a stored state scenario. [33:55.900 --> 34:03.460] So when you visit a website, there's an attack called SSL strip that Moxie Marlin Spike was the first person to really sort of instantiate. [34:04.520 --> 34:09.680] So a common way to visit, say, I'm picking on GitHub, I'm going to keep picking on GitHub. [34:09.840 --> 34:13.580] You type GitHub.com in your web browser's address bar. [34:14.060 --> 34:17.940] That takes you to GitHub via a clear text HTTP request. [34:18.160 --> 34:21.800] GitHub immediately responds and says, no, no, no, no, no, use HTTPS. [34:22.360 --> 34:25.240] And then your client says, okay, no problem, HTTPS GitHub. [34:25.540 --> 34:28.080] And they start the TLS handshake and then we have a nice encrypted session. [34:29.220 --> 34:33.000] So the problem with that arrangement is that when I send... [34:33.000 --> 34:39.100] So there could be a man in the middle sitting or a machine in the middle between me and GitHub servers. [34:39.240 --> 34:41.620] And so that's the little red server there. [34:41.980 --> 34:45.180] So it sees the request and it turns around and just passes it off to GitHub. [34:45.340 --> 34:48.200] And GitHub turns around and says, oh, no, no, you should use HTTPS. [34:48.580 --> 34:51.180] The machine in the middle doesn't send that response back. [34:51.660 --> 34:56.340] Instead, it returns... it turns back to the server and says, okay, fine. [34:56.680 --> 34:58.120] We'll go ahead and do HTTPS. [34:58.260 --> 35:01.300] And GitHub talks to the machine in the middle and says, okay, what are you going to do? [35:02.580 --> 35:09.200] And then the machine in the middle turns around, decrypts the message, because notice that the machine in the middle is the one talking to the GitHub server. [35:10.140 --> 35:13.880] The machine in the middle then turns around and has the clear text communication with me in the first place. [35:14.700 --> 35:17.580] And so I typed github.com in my address bar. [35:17.820 --> 35:22.400] The only change that I would notice is that it didn't turn into a little lock icon. [35:24.460 --> 35:26.420] Otherwise, everything looks exactly the same. [35:26.440 --> 35:30.100] But now somebody is monitoring the traffic and they're sitting in the middle. [35:30.520 --> 35:34.580] So one of the ways to fix this problem is something called strict transport security. [35:34.920 --> 35:40.480] And that's a way that a web server can say to a client, hey, you just visited me via HTTPS. [35:40.880 --> 35:42.940] Never visit me again via HTTP. [35:42.940 --> 35:46.780] If your user types in HTTP, just use HTTPS. [35:47.020 --> 35:51.220] If somebody has an image source that uses HTTP, just use HTTPS. [35:51.600 --> 35:55.200] So just remember, anytime you see anything from me, just use HTTPS. [35:55.340 --> 36:03.920] And then the client remembers that, stores state about which servers it's seen that have this STS header, and never sends an HTTP request again. [36:04.060 --> 36:06.460] So that's a big win, right? [36:06.660 --> 36:09.720] That's a win because we've reduced the amount of clear text communication. [36:09.900 --> 36:11.260] It's a win for confidentiality. [36:13.420 --> 36:16.500] It's not a win for privacy because of the stored state. [36:16.780 --> 36:20.620] So here's an attack that you can do to identify a user. [36:20.840 --> 36:28.020] So users might clear their cookies because they don't want the server to know that they're the same person coming back, right? [36:28.020 --> 36:35.200] I'm going to do some work right now as my, you know, from my activist perspective, and then I'm going to go do some work from my work perspective. [36:35.340 --> 36:38.680] And I don't want the server to know that my activism work is the same as my work work. [36:39.400 --> 36:40.300] I'm actually kind of lucky. [36:40.380 --> 36:42.980] My work work at the ACLU is activism work. [36:43.040 --> 36:44.280] So I don't have to make that distinction. [36:44.460 --> 36:46.020] But other people might not be in that situation. [36:47.520 --> 36:57.680] So what the server can do instead of setting a cookie is the server can serve to the web browser a page that includes, let's say, a dozen images. [36:58.060 --> 37:01.640] Each image from a different host. [37:02.620 --> 37:07.720] Now STS works by saying any connection to this given host should always be secure. [37:08.840 --> 37:18.720] So the server sends a dozen image messages to the client, and the client dutifully goes and fetches those images, because this is what web browsers do, right? [37:18.920 --> 37:19.840] Promiscuous communication. [37:20.180 --> 37:24.140] So it just turns around and makes those communications to all 12 of those servers. [37:24.360 --> 37:26.140] Now this is a colluding pool of servers. [37:27.380 --> 37:35.060] And it could actually all be run on the same server, because you could use these, you could use a, you can use server name indication, right? [37:35.060 --> 37:37.440] To serve several websites from a single page. [37:38.360 --> 37:40.240] So I make a request to 12 of them. [37:40.700 --> 37:42.040] And let's say, what have I got here? [37:42.340 --> 37:46.420] One, two, three, five of them turn around and say, oh yeah, HSTS. [37:46.520 --> 37:47.900] Use strict transport security. [37:48.340 --> 37:49.800] And the other seven don't. [37:51.360 --> 37:56.580] So then the next time I visit this website, the web server wants to know, who is this person? [37:57.500 --> 38:00.740] Oh, by the way, this pool of servers also serves a slightly different image. [38:00.740 --> 38:07.580] It's one pixel larger if it's coming from an HTTPS connection than if it's coming from an HTTP connection. [38:08.520 --> 38:13.680] So the next time the web browser goes to visit the server, the server says, oh, I think I might have seen this person before. [38:13.700 --> 38:15.140] Let me see if I know who it is. [38:15.320 --> 38:19.420] I'll send you this list of images to fetch again from these different servers. [38:19.480 --> 38:22.000] And I'm going to send them all in the clear, all HTTP. [38:23.260 --> 38:27.280] Your web browser is going to remember HSTS from those five. [38:27.640 --> 38:32.140] And it's going to fetch those five via HTTPS and the seven via HTTP. [38:33.420 --> 38:35.120] And it's going to get different images. [38:35.440 --> 38:42.180] Now the JavaScript code running in the page can look at the size of the images and tell which ones were fetched via HTTPS and which ones were fetched via HTTP. [38:43.480 --> 38:49.240] So that's 12 bits of information that the server managed to store on my client. [38:49.240 --> 38:51.520] And so I could have cleared my cookies. [38:51.980 --> 38:58.760] But if I didn't clear my HSTS memory, then the server now knows who I am. [38:59.660 --> 39:07.940] It's also worth noting that whoever is monitoring the traffic here also knows who you are because the traffic patterns of whether it's HTTP or HTTPS are visible to anybody monitoring the network. [39:08.760 --> 39:12.380] So I'm not saying everyone who uses HSTS is doing this. [39:12.500 --> 39:14.160] This is a particularly nasty attack. [39:14.440 --> 39:24.840] But the fact that the client is storing state and remembering it for the purposes of improving confidentiality actually means that they are more vulnerable to some leakage of their identity. [39:25.200 --> 39:27.380] And so it's a privacy problem. [39:29.920 --> 39:31.640] So what can we do about this? [39:33.400 --> 39:34.760] I think there's a set of principles. [39:34.900 --> 39:39.200] I've pointed out to some of the things that are going on, right, like working on things like encrypting SNI. [39:39.520 --> 39:54.540] And I want people who are thinking about tools, people who are thinking about system configuration mechanisms, people who are thinking about user interface, people who are thinking about user experience, to think about these different principles when they're working on these systems. [39:55.100 --> 39:57.760] And keep them in mind because we need to work on privacy. [39:57.940 --> 40:02.000] We need to work on supporting privacy and pushing back against the surveillance against metadata. [40:02.900 --> 40:11.460] So for size and timing, if you're building a tool or designing a protocol, make sure that it offers latency and bandwidth versus privacy trade-offs, right? [40:11.460 --> 40:14.460] Make sure people can pad, make sure people can delay if they need to. [40:14.700 --> 40:16.080] So support those choices. [40:16.280 --> 40:18.100] Yes, those choices will be expensive. [40:18.380 --> 40:20.760] And not everyone is going to decide to pay those expenses. [40:21.320 --> 40:28.140] But if you design your system so that it can't support those expenses, then people who want privacy can't even pay that cost. [40:28.300 --> 40:29.420] So support those things. [40:30.880 --> 40:33.260] For routing, routing's a tough one, right? [40:33.340 --> 40:34.900] Message has to get from point A to point B. [40:35.300 --> 40:37.500] But we have alternate routing infrastructure, right? [40:37.540 --> 40:38.900] We've got Tor, we've got I2P. [40:38.900 --> 40:46.280] There's a couple of other interesting cryptographic masked mixed network kind of routing things that are going on. [40:46.460 --> 40:49.660] Try to support that natively in your protocol or your tool if you can. [40:51.300 --> 41:06.420] For authentication purposes, one of the big takeaways from all the discussion about metadata and systems analysis is that you can set up an encrypted anonymous tunnel. [41:06.420 --> 41:11.540] Now, I know I just said that encryption doesn't mean anything if it's anonymous, if it's not, if there's no authentication. [41:11.540 --> 41:16.700] But you can set up an anonymous encryption tunnel, and then do the authentication on the inside of the tunnel. [41:17.740 --> 41:22.300] So that doesn't protect you against someone who is actively a machine in the middle of the communication. [41:22.300 --> 41:27.140] Because they can set up two fake tunnels and they're not authenticated, and then they can figure out who you're trying to talk to. [41:27.140 --> 41:32.440] But it does help against somebody who is just passively recording all of the data on the Internet anywhere. [41:32.920 --> 41:34.300] Fortunately, no one would be doing that. [41:36.120 --> 41:37.840] So, set up an encrypted tunnel. [41:38.120 --> 41:39.720] Do your authentication inside the tunnel. [41:41.400 --> 41:47.240] And then, I also think we need to explore ideas about unlinkable, non-global identifiers. [41:47.640 --> 41:56.180] So, rather than saying that everybody in the world is going to see me as the same person, it's worth thinking about ways that people can see me through a different lens. [41:56.180 --> 41:58.540] So that I'm not publishing a single global identifier. [41:58.820 --> 41:59.880] This is a hard problem. [42:00.640 --> 42:03.880] And I'm happy to talk about it with people more if they're interested later. [42:04.560 --> 42:10.420] As for stored state, I don't think a lot of people are thinking about the privacy consequences of stored state. [42:10.600 --> 42:10.820] Right? [42:10.900 --> 42:14.220] There's a lot of advantages that stored state gives you for subsequent connections. [42:14.400 --> 42:16.560] For speed, for efficiency, for all kinds of stuff. [42:17.160 --> 42:19.300] So, we need to be thinking about that. [42:19.400 --> 42:23.160] And think about how you can minimize privacy sensitive stored state. [42:23.520 --> 42:27.140] So, one of the ways to minimize it is that you can actually offload some of that state. [42:27.240 --> 42:32.720] If the state is global state, like this website offered an HSTS header. [42:32.920 --> 42:39.900] If there was a way that I could publish that globally, so that everybody could look at it, then the fact that I'd seen it once wouldn't mean anything. [42:39.940 --> 42:44.060] Because I could have gotten it from this global repository of information about who's offering HSTS. [42:44.280 --> 42:46.120] And I could have gotten it from the old web server. [42:46.120 --> 42:49.900] And so then that fingerprinting attack against HSTS would fail. [42:51.080 --> 42:55.480] So, think about how to offload some of... if there's global state that we can offload... [42:55.480 --> 42:59.120] Sorry, if there's local state that we can offload to globally, that would be really useful. [43:00.260 --> 43:02.980] There's also a pretty great RFC. [43:03.180 --> 43:05.260] I don't know how many of you guys read RFCs. [43:06.160 --> 43:09.420] But these are requests for comments that come out of the Internet Engineering Task Force. [43:09.420 --> 43:12.500] And there's a very interesting one about privacy. [43:12.760 --> 43:14.940] And this was written last year. [43:15.200 --> 43:21.360] So we've been doing security considerations in IETF documents for years and years and years. [43:22.960 --> 43:30.420] This is the first time anyone has actually suggested that we really need to think about privacy considerations as a first order thing. [43:30.540 --> 43:32.880] I recommend reading that if you're interested in protocol design. [43:35.500 --> 43:39.640] Concretely, for some things, you know, for concrete protocols that we might be working on. [43:39.840 --> 43:42.220] For transport layer security, encrypt the whole handshake. [43:42.460 --> 43:42.740] Right? [43:42.860 --> 43:44.340] This is... or as much of it as possible. [43:45.100 --> 43:45.880] Support padding. [43:46.400 --> 43:49.700] There's a push going on right now to make sure these things happen for TLS 1.3. [43:51.220 --> 43:55.280] The discussions about what happens in TLS are mailing list discussions for the most part. [43:55.420 --> 43:57.040] There's a meeting next week as well in person. [43:57.260 --> 43:58.940] But much of the discussion is mailing lists. [43:59.120 --> 44:02.720] If you can operate a mail client, you can participate in the discussions. [44:03.200 --> 44:12.840] So if you want to get involved with a transport layer security working group and say, Hey, I do think we need to make sure that we offer the possibility of padding. [44:13.160 --> 44:15.060] Hey, I do think we should be encrypting SNI. [44:15.980 --> 44:21.800] The more people who can make cogent, reasonable arguments and say, We're willing to pay those costs. [44:22.720 --> 44:24.280] Let's make sure that thing happens. [44:24.420 --> 44:28.380] The more likely we're going to actually get these protocols in place so that people can have these protections. [44:30.380 --> 44:33.520] So for email, encrypt your SMTP connections. [44:34.800 --> 44:38.360] There's a mechanism for triple wrapping messages, which would actually hide some headers. [44:38.560 --> 44:40.900] I haven't seen anybody actually doing that in the real world. [44:41.140 --> 44:44.140] Supposedly it's a military grade thing, which always makes me skeptical. [44:45.520 --> 44:49.080] But it would be worth exploring that if people are interested in trying to protect email better. [44:51.080 --> 44:55.180] For chat, there are mechanisms that involve avoiding handshakes entirely. [44:55.900 --> 44:58.840] Which means that you don't have to have any kind of cryptographic signatures involved. [44:58.980 --> 45:01.840] That's an interesting thing if you're interested in deniability issues. [45:02.520 --> 45:05.420] I'm not convinced that deniability is legally particularly effective. [45:05.720 --> 45:08.160] But it's worth looking at that. [45:08.760 --> 45:13.260] And then it's also worth looking at the rendezvous servers, which are related to the chat protocol. [45:13.840 --> 45:21.620] For the web in particular, like I said, we need to expose some of these indicators in global states so that people don't have as much fingerprint ability. [45:21.920 --> 45:23.540] We need to have OCSP stapling. [45:23.900 --> 45:27.080] And we need to have that in a by default fashion. [45:29.260 --> 45:35.280] So just to wrap up here, we have for years been optimizing our networks for confidentiality. [45:36.160 --> 45:38.080] Well, maybe not so much for confidentiality. [45:38.180 --> 45:40.140] We've been optimizing for bandwidth and latency for sure. [45:40.860 --> 45:45.080] We've been done some yeoman's work for optimizing for confidentiality. [45:45.280 --> 45:47.420] But privacy has really fallen by the wayside. [45:47.560 --> 45:48.920] And I think we're missing out on that. [45:49.260 --> 45:51.220] So I want to point out that... [45:51.220 --> 45:55.820] I want people to start thinking about privacy as sort of a first level on the order with all the rest of those. [45:57.040 --> 45:57.800] That's my point. [46:07.280 --> 46:08.980] I'll take some questions here if we've got time. [46:23.580 --> 46:25.100] Yes, that's definitely true. [46:26.140 --> 46:27.400] Sorry, I was trying to get back to it. [46:27.480 --> 46:30.480] And now I'm realizing I've got to scroll around over here, which I can't do. [46:33.600 --> 46:35.200] Yeah, so the CRLs... [46:35.200 --> 46:37.440] So CRLs are an interesting set of trade-offs, right? [46:37.500 --> 46:42.920] A CRL says, rather than I ask you about a given server and you reply... [46:42.920 --> 46:45.640] Sorry, let me see if I can find that OCSP diagram. [46:48.440 --> 46:49.320] I ask... [46:49.860 --> 46:50.300] Yeah. [46:50.920 --> 46:57.340] So rather than asking the server about a particular certificate, I go to the server and I say, hey, give me a list of all of your revoked certificates. [46:58.100 --> 46:59.440] That's how a CRL works. [46:59.540 --> 47:00.640] So that protects the privacy. [47:00.860 --> 47:09.620] The downside of that is that when you have a catastrophic global network event like Heartbleed, the number of revoked certificates is enormous, right? [47:09.620 --> 47:12.620] If a certificate authority has issued, let's say... [47:14.460 --> 47:16.860] Let's say they've issued a million certificates, right? [47:17.300 --> 47:26.560] If each response is a signed response, or the certificate needs to be identified, you end up talking about megabytes of CRLs. [47:27.180 --> 47:32.060] And so you need to have your browsers check in and pull these megabyte-sized files. [47:32.380 --> 47:36.120] This is something people are going to be reluctant to do, particularly when people are paying by the kilobyte. [47:37.140 --> 47:42.520] So the CRL set mechanism is that your web, the Chrome in particular, is doing this. [47:43.980 --> 47:48.120] Google decides, here's a set of certificates that have been revoked that we think are... [47:48.120 --> 47:49.660] it's important that have been revoked. [47:50.800 --> 47:55.140] And so we're going to actually just push those directly into the browser. [47:55.140 --> 47:57.520] So the browser knows about a preset list. [47:57.720 --> 47:59.240] It's a much smaller data set. [47:59.420 --> 48:04.300] And hey, you're going to update your browser every couple of weeks anyway, because the old version was buggy. [48:04.300 --> 48:07.160] The new version's definitely not buggy, but the old version was buggy. [48:08.640 --> 48:11.700] And so if you're going to update it anyway, you might as well get these CRL sets. [48:12.040 --> 48:15.320] So yeah, that is a mechanism that probably is better than... [48:15.320 --> 48:19.340] It's definitely better than OCSP, but it doesn't cover the vast majority of websites. [48:19.640 --> 48:22.700] It's only going to cover the ones that Google thinks are important. [48:22.960 --> 48:28.240] Which probably means, you know, PayPal and Google and systems like that. [48:28.380 --> 48:32.460] But I don't want everybody else to get left out in the cold just because they're not a major financial conglomerate. [48:33.680 --> 48:35.240] We have a question over here. [48:38.380 --> 48:41.500] So the question was, how is Namecoin in relation to these issues? [48:43.760 --> 48:53.020] So for folks who don't know, Namecoin is a way to do global naming based on a blockchain approach similar to Bitcoin. [48:53.020 --> 48:55.880] So probably folks here all know about Bitcoin. [48:56.240 --> 49:05.460] But let me just like point out, Bitcoin is another system that has totally thrown over privacy for the sake of its other political goals, right? [49:05.560 --> 49:12.360] The goals of Bitcoin appear to be to have a currency that's not dictated by government, but it's dictated by compute power. [49:14.760 --> 49:19.280] And all transactions in the Bitcoin blockchain are public. [49:19.820 --> 49:32.480] They may not be directly tied to an individual, but because all of the transactions, because the purse to purse transactions are public, you can do some pretty incredible and privacy invasive analysis of the blockchain. [49:33.200 --> 49:46.600] In fact, there's a paper, I think it was by Shamir, that did some analysis and has some great graphs of Bitcoin transactions showing people trying to sort of hide, you know, doing little Bitcoin laundering. [49:46.780 --> 49:51.240] So they say, oh, well, this guy just got 10 Bitcoins, splits it up into 100 purses. [49:51.540 --> 49:53.740] Those purses then recombine into some other one. [49:53.740 --> 49:57.620] And you can, you know, if you do, if you know your graph theory, you can find those things out. [49:57.920 --> 50:05.500] All trans, if all transactions in the world are globally auditable, then that's actually a privacy loss, not a privacy win. [50:05.960 --> 50:08.960] So I actually think that name, and Namecoin is building on the same infrastructure. [50:09.260 --> 50:18.300] So when you see something change, like a domain name change hands, you'd see that name change hands and you'd be able to track and see who else controls that same name. [50:26.700 --> 50:28.340] So, I'm not sure that I understood the question. [50:28.440 --> 50:32.020] The question was if you had Namecoin based on zero cash, but I don't know what zero cash is. [50:36.480 --> 50:37.160] Ah, okay. [50:37.580 --> 50:40.880] So, so yeah, I want to talk about that afterwards. [50:40.980 --> 50:43.180] Apparently zero cash is supposed to hide the transactions. [50:43.340 --> 50:44.400] I'd love to see how that works. [50:45.860 --> 50:47.020] There's a question in the back there. [51:14.920 --> 51:17.200] Yeah, so, um, thank you. [51:17.440 --> 51:20.560] So the question was about the protocol design within the IETF. [51:21.060 --> 51:27.640] And, um, in particular, whether the protocol design is being dominated by, uh, large corporations. [51:28.040 --> 51:34.200] Um, people with giant web server farms, people who build browsers, as opposed to just other, other interested parties. [51:34.200 --> 51:44.540] The answer is, um, and in particular, HTTP 2.0 was called out as something that would be useful only for these very large entities and probably not for other people. [51:45.380 --> 51:52.600] So, I think the answer is that yes, currently the IETF is heavily dominated by the large entities that are, that are doing this stuff. [51:52.600 --> 51:59.860] Um, one of the reasons for that is there aren't enough of us who are not from large corporations participating. [52:00.600 --> 52:05.820] So, the big corporations have come in and said, yeah, we want the new standards to work this way. [52:05.820 --> 52:07.060] We're writing our tools to work this way. [52:07.180 --> 52:09.620] And we're going to publish them so that you know how to interoperate with our services. [52:10.000 --> 52:11.560] And we'll do that through the IETF. [52:12.040 --> 52:17.840] And that's actually probably the most reasonable thing that they can do, other than, you know, abandon their centralized power. [52:17.960 --> 52:19.400] But that's not going to happen, right? [52:19.920 --> 52:24.920] So, so, so, yeah, and they have a lot of weight to throw around, right? [52:25.040 --> 52:28.500] If Google says, well, sure, you decided that the standard is this, but we're going to do this other thing. [52:28.500 --> 52:32.040] If they were to say that, you know, nobody could really tell them otherwise. [52:32.220 --> 52:34.020] The IETF can't enforce the standards. [52:34.280 --> 52:35.480] There's not, it's not a police body. [52:36.100 --> 52:45.760] Um, but I think what we need is we need more civil society groups active in the standards bodies in order to combat the influence of the large corporations that have their own agendas. [52:46.320 --> 52:49.820] So, I agree with you that there are problems with the, with the standards process. [52:50.040 --> 52:58.400] And I think that the way to solve that is building our own tools, publishing our own specifications, making it clear what our values and our goals are. [52:58.910 --> 53:02.680] And if that involves working with the standards bodies, we should be doing that too. [53:03.680 --> 53:12.300] So, um, so yeah, any, any, if you can help, if there are particular concerns that you have that we, that you think we should be pushing back to, um, please come talk to me. [53:12.300 --> 53:20.520] I'm going to be at the IETF meeting this coming week, talking to folks there and trying to push for, um, more privacy-preserving measures, more confidentiality-preserving measures. [53:20.720 --> 53:24.580] Even if it means that it's going to cost the folks with the big web server farm a little bit more. [53:27.350 --> 53:28.240] So, question here? [53:32.300 --> 53:32.660] Sorry? [53:33.540 --> 53:34.040] Oh, okay. [53:34.160 --> 53:35.520] We've got four minutes to do so. [53:35.660 --> 53:35.880] Okay. [53:36.320 --> 53:37.320] So I should wrap it up then? [53:37.340 --> 53:37.440] Yeah. [53:37.640 --> 53:37.880] Okay. [53:38.260 --> 53:38.620] Sorry. [53:39.080 --> 53:40.320] Um, I have to talk to people afterwards. [53:40.540 --> 53:41.360] So, thank you all. [53:54.080 --> 53:55.380] A huge line outside. [53:55.380 --> 53:57.700] If you're going to stay for the next one, uh, save your seat. [53:58.320 --> 54:00.040] Um, but don't get out of it. [54:11.620 --> 54:11.980] Okay. [54:11.980 --> 54:13.440] Um, yeah. [54:15.160 --> 54:16.560] Um, I don't actually have to move it. [54:16.860 --> 54:17.460] Thank you. [54:18.280 --> 54:21.940] Um, we should move out of the way, whoever's coming up next time. [55:19.400 --> 55:20.600] Uh, [55:36.920 --> 55:41.240] uh, yeah. [55:41.240 --> 55:41.760] Um, uh... [55:41.760 --> 55:43.340] Uh, yeah. [55:43.940 --> 55:45.240] Um, so it's not being right.