WEBVTT 00:04.760 --> 00:09.300 Of course, there's going to be this delay of me watching the screen, seeing if it wakes up. 00:10.320 --> 00:11.660 Yeah, there it is. 00:12.220 --> 00:13.180 I can see you, yeah. 00:16.690 --> 00:19.190 Alright, the swapping around works. 00:25.030 --> 00:27.010 So, welcome everybody. 00:27.010 --> 00:28.710 We'll get started here in about a minute. 00:28.710 --> 00:30.110 I don't want to rush anybody. 00:35.310 --> 00:36.690 We can see everything now. 00:37.690 --> 00:40.610 Good, the stream seems to be live. 00:42.430 --> 00:50.030 So, for those of you asking where the live QA schedule is, you should be able to see that on the DEF CON website. 00:50.210 --> 01:04.850 For those of you who are ready to ask questions of our amazing speakers, one of whom is standing on a roof and the other is in a yellow room, we will proceed right now, actually. 01:04.850 --> 01:06.770 So, hello everyone. 01:06.770 --> 01:09.330 I'm Fallible, I'm going to be one of your goons. 01:09.330 --> 01:10.650 Syged's over here. 01:10.650 --> 01:17.570 And we have Shah and Hadrian or Hadrian, he didn't correct me earlier when I think I said both. 01:17.890 --> 01:19.030 Any is fine. 01:19.030 --> 01:20.470 Any is fine, alright. 01:20.670 --> 01:28.570 Go ahead and give us a moment, actually tell us the name of your presentation and we'll just get into asking some questions. 01:30.330 --> 01:33.250 So, the presentation is DNS section. 01:35.730 --> 01:38.690 And that's already quite good. 01:38.690 --> 01:41.590 Yeah, it's a really good name, I gotta say. 01:42.070 --> 01:46.670 I love it when there's a nice pun in a presentation name. 01:46.730 --> 01:51.490 So, thank you both very much for joining us for the Q&A portion. 01:53.070 --> 01:59.950 For any of you looking for the presentation, you should be able to find that on the DEF CON YouTube page. 02:01.130 --> 02:09.170 Let's get started with a pre-arranged question that you sent me because you were really, really nice to us. 02:09.170 --> 02:14.090 Which equipment slash tools do I need to perform this attack? 02:17.040 --> 02:19.420 Well, I guess I can answer this one. 02:20.940 --> 02:26.940 Basically, you only need your computer and a few tools we have presented in the talk. 02:26.940 --> 02:31.660 So, one to get hashes and one to break hashes. 02:31.660 --> 02:36.860 So, just an nsect-free worker plus hashcat is much enough to perform this attack. 02:36.860 --> 02:39.340 Obviously, if you have a big GPU, it's much easier. 02:39.340 --> 02:46.160 But even on a CPU, you can use John the Ripper to actually get quite a lot of DNS records. 02:46.260 --> 02:48.640 So, you can really do this at home. 02:48.720 --> 02:55.460 In fact, we've made a little challenge on the website, on the last slide. 02:55.460 --> 03:05.160 And if you want to try the tools specifically on our website, you can send us the hashes you've broken. 03:05.200 --> 03:13.280 And we will put up some scores and see who's the best at it. 03:13.560 --> 03:18.200 So, anyone can try it easily at home, but it's much better with a big GPU. 03:18.200 --> 03:19.680 Oh, it's on now. 03:19.680 --> 03:20.680 That's excellent. 03:20.680 --> 03:29.840 We'll make sure that we put that in the track one chat here, so people can access that without having to guess. 03:30.640 --> 03:31.980 So, good. 03:32.600 --> 03:38.000 And I love that what you've come up with here is something that's very accessible for folks. 03:38.000 --> 03:44.840 And it looks to me like it's a good place for people to enter into doing this type of work. 03:44.840 --> 03:53.120 There's a lot of presentations that go way over folks' heads if they're beginners or having to set up a bunch of extra tools. 03:53.120 --> 03:57.760 And it looks to me like you folks have done one that's going to be very accessible. 03:57.760 --> 03:59.000 So, thank you for that. 04:00.660 --> 04:03.980 So, what did you do with all the data that you got? 04:04.320 --> 04:11.700 How much did you get to pay by insert evil company for the whole data set? 04:12.060 --> 04:13.800 So, what did you do with all this data? 04:14.840 --> 04:17.060 Perhaps I can answer this one. 04:19.380 --> 04:23.020 Surprisingly, perhaps, we have not done anything with it. 04:23.220 --> 04:28.560 We have the data and we didn't even exploit it to its fullest potential. 04:29.000 --> 04:31.340 So, we've been very nice and very kind. 04:31.880 --> 04:33.400 That is very nice. 04:33.400 --> 04:35.960 You could have done so much interesting stuff. 04:36.720 --> 04:37.500 Yes. 04:37.500 --> 04:43.500 Extend that a little bit then and help me understand if you wanted to be... 04:44.280 --> 04:53.280 What would be the next step that somebody could take with it and not get ourselves in trouble with the lawyers? 04:54.920 --> 05:00.160 Well, you have already a lot you can do just by looking at the data itself. 05:00.320 --> 05:07.140 That's part of what we've been doing and we've provided statistics about it in the talk. 05:07.500 --> 05:10.600 But really, you can do much more than that. 05:10.600 --> 05:16.260 You can compare the data that you got from this with data you've got from somewhere else. 05:16.260 --> 05:24.400 Either from, I don't know, some other recon tool or from knowledge you've got from research or whatever. 05:24.920 --> 05:31.820 So, really, it's just one tool in the whole toolbox you can get to extract information. 05:32.520 --> 05:36.140 I wouldn't say that all the other tools are completely legal. 05:36.140 --> 05:41.940 I wouldn't say that you wouldn't get into trouble by using the information you get that way. 05:41.940 --> 05:45.420 So, use at your own risk and be very careful with it. 05:45.840 --> 05:47.240 But it's public information. 05:47.240 --> 05:48.380 It's publicly displayed. 05:48.380 --> 05:52.860 It's just that the information itself is meant to be private. 05:52.860 --> 05:56.280 It's meant to be hidden, but it's on public display. 05:57.260 --> 06:01.080 So, I think that's one way to answer your question. 06:01.080 --> 06:17.300 You can really do a lot if you use that data and collate it with other sources of data and actually input whatever you got from, I don't know, email addresses into a database of broken passwords. 06:17.300 --> 06:22.240 And then you get access to that email address, for instance. 06:22.380 --> 06:26.840 And I think Adrien may have other ideas as well, what to do with it. 06:28.500 --> 06:34.440 Actually, legally, other ideas, I think you've pretty much said everything. 06:35.120 --> 06:37.660 I like the restraint there. 06:37.660 --> 06:39.420 That makes a lot of sense. 06:40.040 --> 06:43.600 So, okay, that's useful to know. 06:43.600 --> 06:48.340 So, how much did it cost for you to run this GPU attack? 06:50.140 --> 06:56.540 Well, in practice, it did cost us absolutely nothing, except basically some time to set up the thing. 06:56.840 --> 07:01.800 Because we got access to some free GPU time. 07:01.980 --> 07:11.640 But I did try to estimate how much it would have cost us if we had, for example, just rented an AWS GPU instance. 07:11.640 --> 07:16.600 And I do estimate the cost of the attack between $1,000 and $2,000. 07:18.880 --> 07:37.620 However, if I did only use maybe a tenth of the time we were able to use, I think maybe I found at least 80% of the number of hashes we were able to find with 10 times more power. 07:37.620 --> 07:52.300 So, even without a GPU and only a simple laptop CPU, I think you can get easily maybe two-thirds of the hashes we were able to crack with our big GPU. 07:52.480 --> 07:56.280 Illustrating that classic 80-20 rule, then. 07:57.160 --> 07:58.780 Yes, basically that. 07:58.820 --> 08:00.060 Pretty much. 08:00.740 --> 08:05.080 We do have a couple of questions from the chat, if you'd like to... 08:05.080 --> 08:11.320 So, one is, what are some additional examples of confidential information that are being stored in DNS? 08:13.460 --> 08:17.260 So, the question is whether there were confidential information. 08:18.720 --> 08:29.260 I think they're asking, other than the emails that you were able to pull out, was there other examples of information that people would expect to be confidential that you were able to pull out? 08:30.500 --> 08:34.200 Adrien, perhaps you can say more about the kind of things we found. 08:36.220 --> 08:46.480 Specifically, on OVH, there was nothing else we were able to find, and we did not really look much for other kinds of data. 08:46.480 --> 08:49.540 We were quite happy with what we found there. 08:49.540 --> 08:54.540 But there are some other examples of such private info. 08:54.540 --> 09:01.300 For example, if you take domain key records, some people might know about this. 09:01.300 --> 09:08.000 It's one of the various DNS records you put up to avoid email spam and things like that. 09:08.000 --> 09:24.260 There's a very recent article, or blog post, I forgot, about someone mining for all these domain key records and finding out which mailer different companies use, and which is their email partner. 09:24.540 --> 09:30.800 It was able to dig quite a lot of valuable information, also for the use of DNS records. 09:30.800 --> 09:38.860 And I'm pretty sure there are many other uses of private info in DNS data, but it's not so easy to find it. 09:39.100 --> 09:54.340 And if I may add to this, although the email addresses may seem like it's a small thing, it actually is the basis on top of which we could explore further, find the names of people, find new hosts to target. 09:54.540 --> 10:02.180 And even some private information about these people, because the email addresses show that they were working at the same company, for instance. 10:02.560 --> 10:07.200 So it's an email address, but even then you can say a lot from this. 10:07.720 --> 10:16.500 So there was a follow-up question of whether you meant domain key as DKIM, is that what you're referring to? 10:16.500 --> 10:21.300 I think DKIM and domain key is something different. 10:21.520 --> 10:25.100 I forgot exactly, but it's kind of the same thing. 10:25.100 --> 10:27.980 And if it's not the same, it's another protection for email. 10:27.980 --> 10:43.780 Clearly in the DNS, it shows up at something.__domainkey.yourdomain, and bad people use easily guessable something, and good people use a long hash for something. 10:43.780 --> 10:51.160 And people who do use a long hash for something make it very difficult to find their domain key. 10:54.080 --> 10:58.280 I would need to check out for the domain key versus DKIM thing. 10:59.960 --> 11:04.120 I love this other question that came in as well from Angel Rain. 11:04.200 --> 11:08.180 What is the impact to me, the general internet user? 11:08.240 --> 11:11.140 Which is always a nice thing to be able to encompass. 11:12.080 --> 11:17.180 How is this going to affect somebody who is just out there trying to do their job? 11:19.480 --> 11:25.780 Well, if you are an OVH customer, then you might have quite some issues. 11:25.880 --> 11:40.280 If you do have some private email redirection, then I would suggest you to use one of the mitigation we talked about in the talk. 11:40.280 --> 11:51.460 If you are not an OVH customer, well, I guess I would just log on to my cloud provider and watch my DNS zone and see if there are some records. 11:51.460 --> 11:53.020 I was not expecting that. 11:53.020 --> 11:57.140 And if there are, well, do submit a talk for DEF CON next year. 11:59.040 --> 12:00.980 Now that's good advice. 12:02.460 --> 12:03.660 Okay. 12:04.320 --> 12:09.160 Well, let's move on with one of the other questions that you've posted for us here. 12:09.420 --> 12:13.460 Why does DNSSEC only use old crypto? 12:14.700 --> 12:17.020 Perhaps I can take this one. 12:17.240 --> 12:26.700 Old crypto is not nice, but it is a lot of the things you would see some years ago on the internet. 12:26.700 --> 12:37.440 And now most of the internet, I mean, the browsers and servers have moved on to other algorithms that are faster and some of them are even considered more secure. 12:37.440 --> 12:42.640 But DNS, you have to understand DNSSEC works under a lot of constraints. 12:42.640 --> 12:47.540 It has to be very, very fast because it's used at scale. 12:47.700 --> 12:50.300 So you cannot use all the algorithms you'd like. 12:50.300 --> 12:52.180 You have to use the fastest ones. 12:52.180 --> 13:02.960 And that's actually been a reason why cryptography took a long time to get inside of DNSSEC to the extent that it is now. 13:02.960 --> 13:13.040 Because even today we're deploying security extensions and we have to account for cryptographic operations taking time and latency. 13:13.040 --> 13:24.620 You also have to account for compliance because some technologies are constrained by laws in the different countries that you would be in. 13:24.620 --> 13:36.240 And therefore, if you want to use DNS, which of course you do worldwide, you have to account for the fact that some technologies are not considered legal or accepted in some places. 13:36.240 --> 13:48.400 So you have to deal with a very small subset of the possible algorithms and you have to have all the DNS resolvers and all the DNS servers supporting these algorithms. 13:48.480 --> 13:50.160 And you have to be fast. 13:50.160 --> 14:01.680 So you are playing at a lot of different constraints and that reduces the set of possible algorithms you can use to essentially two of them or three of them. 14:01.680 --> 14:04.060 One is not usable at all. 14:04.060 --> 14:04.880 It's RSA. 14:04.880 --> 14:07.420 It's not really usable at all at scale. 14:07.540 --> 14:12.300 And the other is ECDSA, which you can use to sign very fast. 14:12.300 --> 14:17.300 But it's on a fixed curve, which from a cryptographic standpoint is not ideal. 14:17.300 --> 14:28.480 It means you cannot build on all the innovations of the 21st century to try and get the best performance and the best security out of this. 14:28.480 --> 14:35.920 So really that's the reason you need to do things fast at scale while keeping governance happy. 14:36.200 --> 14:41.780 That's a rough combination of things to deal with if you're trying to future-proof your technology. 14:41.780 --> 14:47.120 It has to be fast, so some of the methods that we have aren't going to immediately work there. 14:47.120 --> 14:50.520 And you have to have compatibility with the old stuff. 14:50.520 --> 14:53.680 So, interesting. 14:53.680 --> 14:58.780 Alright, so another side question on this one. 14:58.780 --> 15:05.360 How did you find yourselves doing the testing on DNSSEC in the first place? 15:05.960 --> 15:08.400 I think Adrien should answer this one. 15:08.400 --> 15:13.020 Well, actually I think we explained that in the talk. 15:14.020 --> 15:15.240 Sorry, it was nice. 15:15.240 --> 15:23.040 It happens that I am an OVH customer for many, many years. 15:23.180 --> 15:30.000 And one day I just did a redirect on my domain just to test what it would do. 15:30.000 --> 15:36.660 And then I did realize that, well, something could transport in the DNS zone. 15:36.660 --> 15:42.100 And from there I just thought that maybe I'm not the only one to have such a behavior. 15:42.160 --> 15:49.500 So I did try on a client domain first, and same issue, and then you guess what happened. 15:51.950 --> 15:54.370 And then we see what happened. 15:54.390 --> 15:54.990 Yeah. 15:54.990 --> 15:55.870 Yes. 15:58.790 --> 16:01.930 Saga, you mentioned you might have another couple of questions. 16:01.930 --> 16:05.130 You're welcome to drop those in whenever you might like to. 16:05.890 --> 16:07.880 So , other things that you've... 16:10.970 --> 16:19.870 Can you give me any idea of where you would have gone with this research had you more time or had you more... 16:22.150 --> 16:28.170 Let's go with more permissions, if you had been told by somebody that you were allowed to. 16:28.170 --> 16:34.010 Is there some space that you would have liked to have gone with this presentation? 16:35.750 --> 16:46.090 Well, one thing, assuming I had all permission, would have been to actually send an email to people we were able to find data about. 16:46.090 --> 16:51.930 And ask them first if they didn't know that their redirections were almost perfect. 16:52.070 --> 16:57.790 And other thing would be to ask them to tell us which redirect we did not find. 16:57.790 --> 17:05.510 So we get a better idea of what kind of plaintext we were not able to recover from our hashers. 17:05.710 --> 17:08.950 So, two ideas which I consider are not evil. 17:08.950 --> 17:14.270 It would be some research thing, but would have required more permission. 17:15.370 --> 17:17.130 Remy, any other idea? 17:17.550 --> 17:21.210 Well, in the more evil kind of things we could do, of course. 17:22.470 --> 17:27.630 As I mentioned earlier, we could collect this information with other information we have. 17:27.790 --> 17:32.210 For instance, all the hosts that people use to receive their emails. 17:32.210 --> 17:36.670 Well, most of them were Gmail, so it's not necessarily the most interesting things. 17:36.930 --> 17:40.130 But some of them are not, and we could look into these. 17:40.130 --> 17:49.010 And we could try and see the proportion of email addresses that are self-hosted or that are hosted in known-to-be-vulnerable domains. 17:49.010 --> 17:51.330 That would also be extremely interesting. 17:51.330 --> 18:10.870 As I also think we say in the talk, we could look at the pwned email databases or pwned addresses database to see how much of these redirects are actually directly usable by people in the know to get an account and to use. 18:10.870 --> 18:17.650 So these are two things that we'd be curious to know about, which are perhaps a bit less nice, of course. 18:21.140 --> 18:22.060 Good answers. 18:22.060 --> 18:23.880 All right, I like where you're heading on that one. 18:24.040 --> 18:28.060 There was a follow-up question in the chat over here from Overdrive. 18:28.200 --> 18:35.660 Although there is an RFC to add EDSA to DNSSEC, why isn't it used more widely, even though it... 18:35.660 --> 18:37.820 Maya, I'm talking here. 18:37.820 --> 18:42.400 Even if it answers all the caveats, performance and security you talked about. 18:42.400 --> 18:49.140 So why isn't it used more widely, EDSA? 18:49.160 --> 18:50.040 ECDSA. 18:50.780 --> 18:53.120 I think I can answer this one. 18:53.120 --> 18:54.620 ECDSA is being deployed. 18:54.620 --> 19:01.280 So it is at the time that we're talking, it's widely deployed, it's getting almost there. 19:01.280 --> 19:03.360 It wasn't true a few years ago. 19:04.360 --> 19:13.060 So really, the question is more about what took so long before we started implementing ECDSA at scale. 19:13.340 --> 19:16.700 And perhaps, I mean, I don't have the full answer to that. 19:16.700 --> 19:24.620 But perhaps part of the reason is that it wasn't clear which solution to zone walking should be implemented. 19:24.740 --> 19:32.860 As we mentioned in the talk, the issue of zone walking has been identified fairly early on on NSEC. 19:32.860 --> 19:40.280 And so NSEC2 and NSEC3 have been proposed, NSEC4 has been proposed as well, NSEC5 has been proposed. 19:40.280 --> 19:50.720 And the problem is, and most of them, NSEC2 and NSEC4 didn't see the light, NSEC4 has not been finalized, NSEC5 has not been finalized. 19:50.720 --> 19:57.060 So people were waiting, perhaps, on a solution to emerge, to be stable, to support. 19:57.060 --> 20:03.560 Because again, when you're doing DNS, when you're doing backbone of the internet kind of things, you want to support things very long term. 20:03.560 --> 20:13.600 So there was an expectation that some of the candidates would happen to be the right one, and that did not happen for a very long time. 20:13.600 --> 20:22.340 And in fact, ECDSA is not the best candidate, it's just the best available candidate using existing technology. 20:24.600 --> 20:30.920 It accomplishes enough of the pieces and there's no better idea right now, huh? 20:31.400 --> 20:32.680 Interesting. 20:32.680 --> 20:37.380 You gave me one final question over here, which seems like it's a little more fun. 20:37.380 --> 20:42.660 So there was a slide with a locksmith on the DNSSEC rollover session slides. 20:42.720 --> 20:46.860 What is the story behind the slide with the locksmith? 20:49.720 --> 20:59.500 Okay, well, so it's during a DNSSEC rollover key session. 20:59.500 --> 21:03.320 So something that happens, if I remember correctly, maybe every three months. 21:03.680 --> 21:13.680 And it's like a very scripted ceremony with many steps and everyone getting things out of the safe, signing the keys, putting them back, auditing everything. 21:13.680 --> 21:25.440 And it happens, and maybe one day before the ceremony, during a rehearsal, they saw that one of the safes containing one of the HSMs was jammed. 21:25.560 --> 21:27.380 So what do you do? 21:27.380 --> 21:33.660 Well, you do have to crack the safe open, and so they had to hire a locksmith to open it. 21:33.660 --> 21:37.900 I think it took 28 hours to open it, so a lot of work. 21:37.900 --> 21:43.440 And so they had to pay everyone two more hotel nights because they had to delay the ceremony. 21:43.680 --> 21:50.340 So even with cryptography, you sometimes have to get back to your old locksmith and crack safes open. 21:51.140 --> 21:55.940 Ah , physical security is never out of style, is it? 21:56.020 --> 22:08.400 No, but at least since it took the locksmith like 28 hours to open it, I'm hoping that any bad people would have been detected before they were able to actually open the safe. 22:09.640 --> 22:12.940 That is kind of the thing with the safe cracking, right? 22:12.940 --> 22:16.520 You're always going to be able to get in, you just hope it takes long enough to be noticed. 22:19.460 --> 22:20.260 Fantastic. 22:25.020 --> 22:31.840 I think I already asked part of this, but we'll hit it again just to make sure we cover our bases. 22:33.140 --> 22:46.420 Where would you want somebody else who has a different set of skills or a different amount of time or a different background to do their own research on this subject? 22:46.420 --> 22:54.120 Is there something that you would point someone towards if they were looking for a research topic of their own? 22:55.880 --> 22:58.200 I have a ton of that. 22:58.200 --> 23:01.040 Adrien may have others as well. 23:01.460 --> 23:11.380 Perhaps I can start by saying that, as I hinted to, DNS is something that has to be understood at a global scale. 23:11.380 --> 23:26.840 And something that should be understood is that, although it's all virtual and it's all the internet, it really is made of servers that have a physical implementation somewhere, that are under some jurisdiction somewhere. 23:26.840 --> 23:43.560 And something I would like people to look into is the geopolitics of how these whole agreements and choice of algorithms and choice of position where you put the servers, the latency as a function of geography. 23:43.560 --> 24:04.500 All the interconnections between the backbone of the internet and the way most people use it, make it transparent, but really it matters, and the geopolitics, so the influence of international agreements, discussions, not only economical but also political. 24:04.500 --> 24:07.320 That would be one thing I'd like people to look into. 24:07.320 --> 24:08.320 Ah, do you hear that? 24:08.320 --> 24:17.780 All of you folks who are into international politics and where the lines get drawn, you have somebody who would like to work on you from the technical side. 24:19.040 --> 24:19.660 Absolutely. 24:19.660 --> 24:21.940 Adrien, I think, has many ideas as well. 24:23.360 --> 24:27.480 On this very specific subject, not so much, actually. 24:27.480 --> 24:35.560 The best idea I had was actually about the domain key thing I just told before, but someone already did it like two months ago. 24:35.560 --> 24:37.220 Very good. 24:37.560 --> 24:41.500 It shows that we're not the only ones looking at DNS records. 24:43.480 --> 24:52.580 And then, a more general thing, you could consider this leakage almost like some kind of side-channel attack. 24:52.900 --> 25:04.760 It's some kind of very low-tech side-channel attacks, and I'm pretty sure there are many other areas where you could find public data where you're not expecting it at all, just where it's a little hidden. 25:04.760 --> 25:26.860 So, there's a little of luck you need, because you need to find the first record, but if one day you do find some public info that you were not supposed to find, well, try to dig up behind it and find out if it is just one, or if there are thousands of such info in the same place. 25:28.240 --> 25:33.600 I also have a suggestion for the more cryptography-oriented people. 25:33.600 --> 25:40.520 The way that zone-walking is mitigated is by using white lies. 25:40.600 --> 25:46.900 So, you would sign a lot of information, and so you can force the server to produce a lot of signatures. 25:46.900 --> 26:05.460 ECDSA is famously a brittle algorithm, and so if the implementation on the server is not absolutely perfect, it's quite likely that by collecting millions, billions of signatures, you can actually obtain the private key with known techniques. 26:05.460 --> 26:26.720 So, one thing that we didn't look into, but you may want to check, is, okay, can I find DNS servers that have not the latest OpenSSL library, say, use known attacks against ECDSA and forcing the white lies mechanism to obtain the necessary signatures, 26:26.720 --> 26:29.680 and then perform a DNS spoof? 26:30.040 --> 26:32.520 Something like this might be interesting. 26:32.520 --> 26:35.400 That is a nice sequence of events there. 26:35.400 --> 26:38.160 I like where you're going, so it'll be neat to see if somebody... 26:38.160 --> 26:53.140 Just to add on this, I have already tried a few millions to get a few million records and try non-3Us on it, so the most basic ECDSA attack, and it was not successful, but maybe some more advanced attacks would actually work. 26:54.840 --> 27:09.420 We will make sure that we have your contact information in the track one channel over here at the end of this, so that people can ping you if they would like to talk about this further. 27:09.420 --> 27:19.600 In fact, now is probably a good time to make sure that, is there a place that you would like for people to reach out to you if they have more questions or thoughts about the work that you've been doing? 27:21.920 --> 27:26.140 dnssection.ovh, and you have all the contact info on this website. 27:26.140 --> 27:30.260 So, that's the website to put on the chat. 27:30.520 --> 27:31.280 Perfect. 27:31.680 --> 27:34.300 We'll get somebody to drop that in there for us. 27:35.740 --> 27:40.080 So, Sajed, I don't want to just bulldoze you here. 27:40.080 --> 27:46.500 If you have another thought for us right now, then if you have a question, drop us with that before I do our closeout. 27:49.400 --> 27:53.180 So, we do have one more question from the audience. 27:53.500 --> 28:02.160 It was asking about geopolitically, where do you see CA providers fitting in, say, borders of countries that are apt to be taken over? 28:02.200 --> 28:08.460 Would you personally prefer a CA provider being further away from those borders, or do you think it matters at all? 28:09.280 --> 28:15.580 That's an excellent question for which I think there is no easy answer, but that's what makes a good question. 28:15.580 --> 28:21.920 I think the borders are a huge, huge issue. 28:21.920 --> 28:23.600 It does matter. 28:23.600 --> 28:34.940 As you know, CAs are generated usually using machines, dedicated machines, and whoever seizes them has the possibility to do whatever they want with it. 28:34.940 --> 28:48.060 So, yes, indeed, if you have CAs, if you want to have any kind of guarantee about the physical security of something, put it as far away as you can from moving borders. 28:48.060 --> 28:49.080 Absolutely. 28:51.840 --> 28:52.520 Great. 28:52.520 --> 28:52.800 All right. 28:52.800 --> 28:57.820 So, my last question that I like to hit people with is what would be your call to action? 28:57.820 --> 29:16.720 Not just something that you want people to research further, but what would be the core of what you're attempting to get people to understand or to get interested in about the work that you're doing and give people that leg up on moving forward? 29:23.000 --> 29:25.360 That's a complicated question. 29:26.740 --> 29:34.920 I think Adrien already put forward the notion that look around yourself, look around the technology that we use every day. 29:35.040 --> 29:42.700 The more we use it, the less we ask about it, the less we wonder about how it works and why it works and why it doesn't work. 29:42.700 --> 29:47.460 And we tend to be focused on getting work done. 29:47.720 --> 29:49.440 What we do is exactly the opposite. 29:49.620 --> 29:53.360 We're trying to stop and think about, okay, it doesn't work. 29:53.360 --> 29:54.400 It's interesting. 29:54.780 --> 29:55.620 It's like bugs. 29:55.620 --> 29:57.880 You know, people try to kill bugs whenever they see a bug. 29:57.880 --> 30:01.120 And we like more collecting them and say, oh, well, that's nice. 30:01.120 --> 30:05.440 This one has wings and this one is eating some stuff. 30:05.440 --> 30:17.320 So we really try to do that and to call for people to focus on issues, not to try and solve them, but to try and look at issues for themselves as something that's interesting. 30:17.320 --> 30:25.420 And that brings not only solutions, but brings more intelligence, more ideas into the game. 30:25.420 --> 30:26.820 But that's my take on it. 30:26.820 --> 30:30.400 Adrien perhaps might have something more less poetic to say. 30:30.400 --> 30:34.260 No, actually, I do agree with you. 30:34.260 --> 30:38.460 And even like in my other life, I am a software engineer. 30:38.460 --> 30:48.780 And when I do find a bug, even something which is just strange, but never happens again in other circumstances, I always put it for a rainy Friday and try to look at exactly what happened. 30:48.780 --> 31:00.960 And often, more than just this bug, often shows some hidden secrets that we are happy to fix before it actually goes for real. 31:01.180 --> 31:13.620 So as a matter of fact, yes, do look around you and try as much as possible to get to the bottom of strange things to find out if it is only building or if there is a long story behind it. 31:15.020 --> 31:16.820 I appreciate those answers. 31:16.820 --> 31:21.000 And I appreciate the two of you very much for coming to join us for this. 31:21.000 --> 31:27.920 I also am very much entertained by the light mode, dark mode thing we have going on with the outside and in the dark. 31:27.920 --> 31:29.000 So this is cool. 31:29.000 --> 31:34.380 Thank you so much for your presentation and for spending your time with us. 31:34.380 --> 31:45.380 If anybody has any additional questions, they have posted, Oblivia posted the dnssection.ovh in the TrackOneLive QA, so you can find that there. 31:45.520 --> 31:51.260 Otherwise, have a great rest of the convention and we hope to see more from you folks soon. 31:52.720 --> 31:59.240 Well, thank you very much to all DEF CON goons to be able to make this session happen this year. 31:59.240 --> 32:00.900 So thanks a lot to you too. 32:01.400 --> 32:01.920 Cheers. 32:01.920 --> 32:02.360 Thank you. 32:02.360 --> 32:03.140 Bye everyone.