[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:30.110]  So, welcome everybody. We'll get started here in about a minute. 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:09.330]  So, hello everyone. I'm Fallible, I'm going to be one of your goons.
[01:09.330 --> 01:17.570]  Syged's over here. 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:28.570]  Any is fine, alright. 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:46.670]  Yeah, it's a really good name, I gotta say. 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:20.680]  Oh, it's on now. 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:59.000]  And it looks to me like you folks have done one that's going to be very accessible. 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:35.960]  That is very nice. 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:52.860]  But it's public information. It's publicly displayed. 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:39.420]  I like the restraint there. That makes a lot of sense.
[06:40.040 --> 06:48.340]  So, okay, that's useful to know. 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:27.980]  I think DKIM and domain key is something different. I forgot exactly, but it's kind of the same thing. 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:08.180]  I love this other question that came in as well from Angel Rain. What is the impact to me, the general internet user?
[11:08.240 --> 11:17.180]  Which is always a nice thing to be able to encompass. 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:53.020]  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. 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:13.460]  Okay. Well, let's move on with one of the other questions that you've posted for us here. Why does DNSSEC only use old crypto?
[12:14.700 --> 12:26.700]  Perhaps I can take this one. 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:47.540]  But DNS, you have to understand DNSSEC works under a lot of constraints. It has to be very, very fast because it's used at scale.
[12:47.700 --> 12:52.180]  So you cannot use all the algorithms you'd like. 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 --> 14:01.680]  And you have to be fast. 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:12.300]  One is not usable at all. It's RSA. It's not really usable at all at scale. And the other is ECDSA, which you can use to sign very fast.
[14:12.300 --> 14:28.480]  But it's on a fixed curve, which from a cryptographic standpoint is not ideal. 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:47.120]  That's a rough combination of things to deal with if you're trying to future-proof your technology. It has to be fast, so some of the methods that we have aren't going to immediately work there.
[14:47.120 --> 14:53.680]  And you have to have compatibility with the old stuff. So, interesting.
[14:53.680 --> 15:05.360]  Alright, so another side question on this one. 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:23.040]  Well, actually I think we explained that in the talk. Sorry, it was nice. 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:42.100]  And then I did realize that, well, something could transport in the DNS zone. 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.990]  And then we see what happened. Yeah.
[15:54.990 --> 15:55.870]  Yes.
[15:58.790 --> 16:05.130]  Saga, you mentioned you might have another couple of questions. 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:14.270]  So, two ideas which I consider are not evil. 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:00.790]  As I also think we say in the talk, we could look at the pwned email databases or pwned addresses database
[18:00.790 --> 18:10.870]  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:23.880]  Good answers. 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:53.120]  ECDSA. I think I can answer this one.
[18:53.120 --> 19:01.280]  ECDSA is being deployed. 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:32.680]  It accomplishes enough of the pieces and there's no better idea right now, huh? 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:33.660]  So what do you do? 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:16.520]  That is kind of the thing with the safe cracking, right? 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 --> 23:11.380]  I have a ton of that. Adrien may have others as well. 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:17.780]  Ah, do you hear that? 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:21.940]  Absolutely. Adrien, I think, has many ideas as well.
[24:23.360 --> 24:35.560]  On this very specific subject, not so much, actually. 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:41.500]  Very good. 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:29.680]  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, and then perform a DNS spoof?
[26:30.040 --> 26:32.520]  Something like this might be interesting.
[26:32.520 --> 26:38.160]  That is a nice sequence of events there. 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:30.260]  dnssection.ovh, and you have all the contact info on this website. So, that's the website to put on the chat.
[27:30.520 --> 27:34.300]  Perfect. We'll get somebody to drop that in there for us.
[27:35.740 --> 27:46.500]  So, Sajed, I don't want to just bulldoze you here. 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 --> 28:02.160]  So, we do have one more question from the audience. 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:34.940]  I think the borders are a huge, huge issue. It does matter. 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:49.080]  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. Absolutely.
[28:51.840 --> 29:16.720]  Great. All right. So, my last question that I like to hit people with is what would be your call to action? 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:42.700]  That's a complicated question. I think Adrien already put forward the notion that look around yourself, look around the technology that we use every day. 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 --> 30:05.440]  And we tend to be focused on getting work done. What we do is exactly the opposite. We're trying to stop and think about, okay, it doesn't work. It's interesting. It's like bugs. You know, people try to kill bugs whenever they see a bug. And we like more collecting them and say, oh, well, that's nice. This one has wings and this one is eating some stuff.
[30:05.440 --> 30:30.400]  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. And that brings not only solutions, but brings more intelligence, more ideas into the game. But that's my take on it. Adrien perhaps might have something more less poetic to say.
[30:30.400 --> 30:48.780]  No, actually, I do agree with you. And even like in my other life, I am a software engineer. 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:13.620]  And often, more than just this bug, often shows some hidden secrets that we are happy to fix before it actually goes for real. 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:29.000]  I appreciate those answers. And I appreciate the two of you very much for coming to join us for this. I also am very much entertained by the light mode, dark mode thing we have going on with the outside and in the dark. So this is cool.
[31:29.000 --> 31:51.260]  Thank you so much for your presentation and for spending your time with us. If anybody has any additional questions, they have posted, Oblivia posted the dnssection.ovh in the TrackOneLive QA, so you can find that there. Otherwise, have a great rest of the convention and we hope to see more from you folks soon.
[31:52.720 --> 32:00.900]  Well, thank you very much to all DEF CON goons to be able to make this session happen this year. So thanks a lot to you too.
[32:01.400 --> 32:03.140]  Cheers. Thank you. Bye everyone.