WEBVTT

1
00:00:02.250 --> 00:00:20.699
MTS-AV: Thank you, Scott. Hello, and welcome to the first of two SSAC Lightning Talk sessions. My name is Kathy, and I'm the participation manager for this session. Please be advised that this session is being recorded and is governed by the ICANN Community Participant Code of Conduct, the ICANN Expected Standards of Behavior, and the ICANN Community Anti-Harassment Policy.

2
00:00:20.860 --> 00:00:35.860
MTS-AV: Regarding participation today, this session is designed for internal discussion among SSAC members on current security, stability, and resiliency topics. Observers are welcome to watch, but this session is not open for observer participation unless the moderator chooses to do so.

3
00:00:36.350 --> 00:00:48.280
MTS-AV: For SSAC members, all members have been promoted to panelist status in Zoom. To join the speaking queue, use the raise hand feature, even if you're physically present in the room. With that, I'm happy to hand the floor over to Barry Lieba.

4
00:00:49.490 --> 00:01:00.069
MTS-AV: Okay, this is Barry Liebel with SSAC, and those of you who were not in the room unfortunately missed the sparkling speech I made before the recording was started. Sorry about that.

5
00:01:00.340 --> 00:01:07.820
MTS-AV: But we have the lightning talks, and we'll start with Raffaella, and then pass it on to Peter. So, Raffaella, go ahead.

6
00:01:08.170 --> 00:01:11.430
MTS-AV: Thank you so much. Let me share the screen.

7
00:01:15.740 --> 00:01:16.670
MTS-AV: Hey.

8
00:01:17.090 --> 00:01:20.549
MTS-AV: Then, for some reason or another, PowerPoint doesn't want to present anymore.

9
00:01:34.030 --> 00:01:34.890
MTS-AV: Come on.

10
00:01:35.640 --> 00:01:37.239
MTS-AV: Okay, give me a second.

11
00:01:58.140 --> 00:01:59.840
MTS-AV: That's always

12
00:02:15.240 --> 00:02:15.990
MTS-AV: Okay.

13
00:02:22.680 --> 00:02:26.629
MTS-AV: Okay, welcome, everyone.

14
00:02:26.950 --> 00:02:32.559
MTS-AV: So this first lightning talk will be about a paper that a student of mine, master student of mine, wrote.

15
00:02:32.780 --> 00:02:40.500
MTS-AV: About the reusual of domain validation token at scale from certificate authority, and this paper has been

16
00:02:40.620 --> 00:02:54.990
MTS-AV: Just accepted that WTMC 2026. So I'm very happy. And it's a workshop co-located with CCS. And I'm going to give you a bit of a gist of what this paper is about and the result that we find out.

17
00:02:55.920 --> 00:03:10.620
MTS-AV: So all of you have probably read the news that some hackers obtained counterfeit TLS certificate for Google and other large services by hijacking three top level domains through CCTLD.

18
00:03:11.530 --> 00:03:22.239
MTS-AV: Now, the question that I would like to bring you today is that imagine that if the attacker can keep the control and can keep issuing the certificate even after the Ajax event happened.

19
00:03:22.760 --> 00:03:26.029
MTS-AV: Is this possible in certificate world, and how?

20
00:03:26.920 --> 00:03:27.750
MTS-AV: And…

21
00:03:28.430 --> 00:03:46.509
MTS-AV: The most common model that we have in our head when we think of, okay, someone is doing a domain verification check for a domain name, when requesting a certificate, is this one. This is from a Let's Encrypt paper, describing basically the architecture of Let's Encrypt of a couple of years ago.

22
00:03:46.510 --> 00:03:51.779
MTS-AV: to use Znik Security, where basically a domain owner using the ACME protocol request

23
00:03:51.780 --> 00:04:01.979
MTS-AV: to, the registration authority of the certificate authority, certificate, the certificate authority checks with the validation authority, that is basically the server that they use.

24
00:04:01.980 --> 00:04:16.709
MTS-AV: to validate if the domain owner, basically has the right control over the DNS server, in the case they use a DNS validation, or the web server, in case they use… and the DNS server, of course, in case they use HTTP validation.

25
00:04:18.430 --> 00:04:32.589
MTS-AV: The reality, of course, is not that simple, because we live in a nasty world where people can do nasty stuff. So we have BGP hijacking that can happen, and you don't want to have a certificate authority fall in the trap of BGP hijacked.

26
00:04:33.720 --> 00:04:54.499
MTS-AV: So, what they do, really, is they have multiple validation servers all across the world, because they want to measure the characteristic of this domain web server and this domain DNS server, and check that the records are consistent all across the world to see that, indeed, the result is always the same, and you don't have, like, hijacked path in the middle.

27
00:04:56.870 --> 00:05:11.579
MTS-AV: But there is a problem, that if you start to do this kind of validation in a repeated way, you may overload the domain infrastructure or the CA validation server with catastrophic consequences. I mean, it starts to DDoS, like, infrastructure of.

28
00:05:11.860 --> 00:05:19.729
MTS-AV: Certificate authority by just requesting millions and millions of certificate for a domain.

29
00:05:20.860 --> 00:05:35.490
MTS-AV: Two common mitigations to this. The first one is rate limiting. It's often done by doing a PSL-based suffix, so you are allowed to request up to a certain amount of certificate per minute per TLD.

30
00:05:35.800 --> 00:05:40.970
MTS-AV: Sorry. So per registered domain based on the public suffix list.

31
00:05:41.320 --> 00:05:54.769
MTS-AV: And the second one is doing domain validation caching, the domain control validation caching. That basically means that you cache the information that you retained out of the fact that the domain owner was owning that domain.

32
00:05:54.870 --> 00:05:56.600
MTS-AV: domain.

33
00:05:57.840 --> 00:06:04.020
MTS-AV: In this presentation, we focus on caching and the security risk introduced by reusing these validation results.

34
00:06:05.120 --> 00:06:14.030
MTS-AV: How the caching works, basically, the same picture as before, is that when the second time the domain owner requests the certificate for his domain.

35
00:06:14.030 --> 00:06:26.290
MTS-AV: Instead of doing again all the validation, you have like a phase that it's the DCV caching. Everything is that was previously validated gets stored somewhere. And you can reuse that information for how long you can reuse that information.

36
00:06:26.590 --> 00:06:46.569
MTS-AV: Well, you can reuse that information for, in the past, up to 398 days. Nowadays, it's going down. Now it's… the current is 200 days, because this has been reduced by the CA browser forum, and there is a plan for a gradual reduction of this validation, caching

37
00:06:46.630 --> 00:07:00.780
MTS-AV: Up to 10 days in 2029. The important part is that 96.4% of the domain, certificates out there are domain-validated certificates, so these apply to most of the, certificates out there in the wild.

38
00:07:02.650 --> 00:07:10.189
MTS-AV: What's the problem of doing validation caching? The problem is that domains out there expires.

39
00:07:10.310 --> 00:07:16.080
MTS-AV: They are deleted, they are suspended for phishing or abuse.

40
00:07:16.540 --> 00:07:27.420
MTS-AV: And when they expire, of course, their registration and delegation disappear. And in case you use, basically, a cached information for verifying the ownership of the domain.

41
00:07:27.970 --> 00:07:46.540
MTS-AV: they may not reflect anymore the current controller of the domain name. And if you combine that with, for example, a BGP AJAC, you could get an attacker to obtain a certificate for a domain name that it really doesn't own anymore, and end up with intercepting TLS traffic.

42
00:07:46.680 --> 00:07:53.990
MTS-AV: It's a fairly complicated attack, it's not… it's hard to do in the… in the… in the wild, but it's a potential risk.

43
00:07:56.960 --> 00:08:00.870
MTS-AV: So how do we find how often this happens?

44
00:08:00.990 --> 00:08:07.789
MTS-AV: And the way we find often this happens is that we want to find certificate.

45
00:08:08.430 --> 00:08:12.319
MTS-AV: that have been logged in certificate transparency log.

46
00:08:12.490 --> 00:08:17.709
MTS-AV: With no contemporaneous DNS evidence or registration evidence.

47
00:08:18.020 --> 00:08:30.460
MTS-AV: So, how many of these… how many of these cases we find, how many of these cases have something that is compatible with the reuse of a possible cached token, because there was a certificate in the past that was cached.

48
00:08:30.790 --> 00:08:38.770
MTS-AV: And, how these cases varies across CAs. So, are there CAs that reuse more validation token than others?

49
00:08:40.730 --> 00:08:59.420
MTS-AV: So, to do this, we used a couple of data sources. The first thing, we used Zonestream. Zonestream is a project we run on the OpenIntel, where we basically measure in real time… match in real time all the domain names we learned from CityLog per certificate, that are basically the requests for certificates that are sent to the CityLog.

50
00:08:59.540 --> 00:09:10.520
MTS-AV: against the daily GTL leads on files, and we do that for detecting newly registered domain names, so we do that with the aim of basically creating a stream of newly registered domain names.

51
00:09:10.850 --> 00:09:20.179
MTS-AV: And to confirm that if they are newly registered, we checked with RTOP, and we monitor also the DNS query for the next 48 hours for this newly registered domain name.

52
00:09:20.570 --> 00:09:23.310
MTS-AV: We also use in these

53
00:09:23.430 --> 00:09:37.570
MTS-AV: pipeline DNS Coffee, that's basically an historical overview of the zone files published in CZDS, for checking, for example, if the domain name was active in the 3 days prior or 3 days after the certificate issuance.

54
00:09:37.570 --> 00:09:53.580
MTS-AV: Because certificate log has this problem of maximum merge delay, where the certificate may be requested, but then you may have, like, up to 48 hours for the certificate to get… the certificate request to get inserted into the log. So you need to account for a bit of caveats of timing.

55
00:09:53.950 --> 00:10:06.809
MTS-AV: To account for these caveats of timing, we checked that the first measurement we are able to issue, the NS measurement we are able to issue is within 5 minutes of the issuance certificate request, from the,

56
00:10:07.140 --> 00:10:16.759
MTS-AV: certificate owner, so we are sure that at least when we measure something, we are measuring that 5 minutes after the person clicked on, I want a new certificate under the ACME protocol.

57
00:10:18.190 --> 00:10:27.710
MTS-AV: So, we looked at the entire 2025, and out of 14 million, potentially new domain, we found that

58
00:10:27.970 --> 00:10:36.350
MTS-AV: around 1,800,000 were responding with 404 RTAP. That means that they were not existing, so…

59
00:10:36.470 --> 00:10:39.759
MTS-AV: They were not new domain, they were just not existing domains.

60
00:10:40.020 --> 00:10:43.620
MTS-AV: 284,

61
00:10:43.890 --> 00:10:55.539
MTS-AV: Thousands of these were consistently in NX domain for the next 48 hours. We did measurement every 10 minutes for the next 48 hours, and they always respond with NX domain, so the domain was not existing.

62
00:10:56.140 --> 00:11:05.050
MTS-AV: We filter out the one that were within 5 minutes of… from first measurement from the certificate issuance that brought us to 169,000

63
00:11:05.200 --> 00:11:08.439
MTS-AV: Domains, and we also looked if there were

64
00:11:09.570 --> 00:11:16.800
MTS-AV: appearing, like, in the range of plus-minus 3 days from the Zoom file, and we ended up with a number of 121.

65
00:11:17.280 --> 00:11:19.090
MTS-AV: a thousand domains.

66
00:11:19.280 --> 00:11:32.069
MTS-AV: So, what are these 121,000 domains belonging to 142 certificates? These are potentially certificates that have reused a previously cached validation token out there.

67
00:11:33.740 --> 00:11:48.120
MTS-AV: So, 121 unique domains that has certificate without contemporaneous DNS evidence. And this is, like, a lower bound. This is just one where we can see that there may have been, like, a reusal of a cached validation token.

68
00:11:48.250 --> 00:11:59.700
MTS-AV: Just because there was no DNS evidence. Reusal of validation tokens may also happen in case the domain still exists and still is in control of the user, but we don't have any visibility into that because the certificate

69
00:11:59.720 --> 00:12:08.779
MTS-AV: Authorities do not publish if the certificate was issued because the domain was checked, or was checked by using a cache token.

70
00:12:10.200 --> 00:12:27.720
MTS-AV: So, out of these, 121,000 domains, 111 were, did not reappear in the zone file, and just 10,000 were subsequently re-registered. We don't know if they were re-registered by different people, because, of course, RDAP doesn't give us any information about the registrant.

71
00:12:28.010 --> 00:12:35.669
MTS-AV: But these are… could potentially be re-registered by different people, raising basically this problem of the ownership transfer.

72
00:12:37.320 --> 00:12:38.200
MTS-AV: And…

73
00:12:38.590 --> 00:12:55.180
MTS-AV: you may wonder, okay, can we explain all these cases with the TCP caching? The interesting part is that 91… probably yes, because 91% of these domains had the predecessor certificate from the same issuer within the 398-day reuse window, so there was a certificate in the past

74
00:12:55.370 --> 00:13:09.729
MTS-AV: that had an active domain, an active DNS record that was issued, and then when the domain basically expired, they probably reused that validation token that they collected at the first time back in, when the domain was active.

75
00:13:11.070 --> 00:13:18.909
MTS-AV: We are not 100% sure this is just an empirical observation, because that's what we can observe from big data, but this is probably the most likely explanation.

76
00:13:20.400 --> 00:13:30.010
MTS-AV: If we look at which are the CAA that perform this kind of caching, we try to do that by comparing to their

77
00:13:30.010 --> 00:13:42.079
MTS-AV: actual volume of certificate emission, not just by looking at the number of the domain in general. And we did that because we want to understand more if

78
00:13:42.400 --> 00:14:01.369
MTS-AV: you know, if this caching is just dependent on the number of certificates you issue in the wild, or if it's really something that you try to do more as certificate authority, what we found interesting is that DigiCert and GoDaddy are apparently reusing more and more this caching mechanism compared to the other.

79
00:14:03.460 --> 00:14:13.949
MTS-AV: So why this problem exists at all is that this problem exists at all because basically certificate authority reused domain validation evidence long after the original check.

80
00:14:14.310 --> 00:14:15.520
MTS-AV: And,

81
00:14:16.170 --> 00:14:25.749
MTS-AV: We don't have very historical visibility into DNS, because DNS is queried on demand, and we don't have visibility in temporary zone changes or short-lived

82
00:14:25.890 --> 00:14:28.620
MTS-AV: zone changes inside the DNS.

83
00:14:29.110 --> 00:14:36.420
MTS-AV: And, some CAA may operate, and this is just a speculation on

84
00:14:36.580 --> 00:14:52.970
MTS-AV: private evidence of domain registration. If you are a registrar, you may have information regarding the fact that the domain is still in the control of the previous owner, and you may use that information to issue a certificate if you are both a certificate authority and a registrar, but that's, again, just a speculation.

85
00:14:53.680 --> 00:14:56.659
MTS-AV: And the main question is, shall CA trust

86
00:14:56.850 --> 00:15:04.640
MTS-AV: Get us a toll in, issuing certificates, because we have been… set as the

87
00:15:05.240 --> 00:15:10.010
MTS-AV: The trust anchor for certificate authority, but we never ask for that.

88
00:15:11.580 --> 00:15:23.119
MTS-AV: Luckily, on the CA side, something is moving. In March 2026, there was a ballot, the ballot SC081, where the reuse period was reduced to 200 days.

89
00:15:23.490 --> 00:15:41.239
MTS-AV: And there are further reduce, reduction plan to bring, basically, the validation reuse closer to certificate lifetime that are also being shortened. Now we're talking of certificate of 45 days, at maximum, and then in the future, probably will be 9 or 10 days, and instead the target of

90
00:15:41.320 --> 00:15:46.750
MTS-AV: These domain validation caching will be 10 days by March 2029.

91
00:15:48.570 --> 00:15:54.960
MTS-AV: And with this, I conclude my presentation, and I'm open for questions, or we handle questions after.

92
00:15:56.840 --> 00:15:58.579
MTS-AV: We'll take questions now.

93
00:15:59.280 --> 00:16:02.249
MTS-AV: So Any questions for Rafaela?

94
00:16:03.910 --> 00:16:04.640
MTS-AV: John.

95
00:16:05.870 --> 00:16:13.409
MTS-AV: Yeah, thanks. This is fairly interesting. And I guess the question I was going to ask — Tell everybody recording who you are. Oh, I'm John Lemon, NSSAC member.

96
00:16:15.380 --> 00:16:30.159
MTS-AV: I guess the question I was going to ask, I think, is mostly answered by your last slide, but my understanding is that if you can get the certificate lifetimes down to under a month, which is typically how long the DNS goes dead when a thing expires, you'd think this problem would go away.

97
00:16:30.600 --> 00:16:39.040
MTS-AV: Is that realistic, or do you think there's still going to be CAs that leave stuff around for longer because they want to charge money or something?

98
00:16:39.900 --> 00:16:44.459
MTS-AV: I think this is really sad. I think the main problem here was the initial

99
00:16:44.650 --> 00:16:48.829
MTS-AV: requirement that was set of 398 days. That was completely insane.

100
00:16:49.100 --> 00:17:04.749
MTS-AV: The… setting that to a timeline where you have, like, at least it aligns with the period that usually a registry and registrar keep domain out of the, for example, the possibility of resettling the domain will be enough to avoid this kind of situation.

101
00:17:07.990 --> 00:17:10.619
MTS-AV: We have a question online from Jeff Huston.

102
00:17:12.000 --> 00:17:20.310
Geoff Huston: Geoff Huston, hi, thanks for this. Look, we've come down from 398 days, progressively down to 10.

103
00:17:21.060 --> 00:17:25.480
Geoff Huston: But it may not stop there. Where does it stop? One hour?

104
00:17:25.700 --> 00:17:27.030
Geoff Huston: 10 seconds.

105
00:17:27.390 --> 00:17:29.419
Geoff Huston: What's the logical point?

106
00:17:29.660 --> 00:17:38.579
Geoff Huston: where you can cache material and be assured that that cached material is still valid. Because it strikes me that

107
00:17:38.710 --> 00:17:44.919
Geoff Huston: This really is something that has no logical endpoint, and maybe we're just doing the wrong thing.

108
00:17:47.570 --> 00:17:57.760
MTS-AV: So, to answer to that, I think one of the reasons why they performed… I tried to dig up why this caching even existed, and one of the reasons why

109
00:17:58.400 --> 00:18:04.789
MTS-AV: One likely explanation I found is that really to prevent, Abuse of them…

110
00:18:05.090 --> 00:18:07.610
MTS-AV: certificate infrastructure to do DDoS attack.

111
00:18:07.910 --> 00:18:09.170
MTS-AV: That probably will…

112
00:18:09.340 --> 00:18:20.570
MTS-AV: rate limiting will suffice, but… and even, like, a smaller period will suffice. I really don't know why they started from this very high number.

113
00:18:23.910 --> 00:18:31.210
Geoff Huston: But my question is more, Where does it stop? Because 10 days seems totally artificial as a number.

114
00:18:31.870 --> 00:18:35.429
Geoff Huston: What's wrong with one day? What's wrong with, you know, an hour?

115
00:18:36.570 --> 00:18:49.340
MTS-AV: I think 10 days may be, like, a good compromise between the fact that the main name doesn't get immediately put out for reselling after 10 days, if it gets taken down or if it expires.

116
00:18:50.060 --> 00:18:55.369
MTS-AV: I mean, it's an arbitrary, but I agree with you, it's an arbitrary number, it's an arbitrary decision that…

117
00:18:55.520 --> 00:19:07.039
MTS-AV: they are taking, and I don't have, like, a convincing argument why it should be, like, 10 days, or 1 hour, or… probably it should be, like, the TTL of the… of the…

118
00:19:07.950 --> 00:19:13.110
MTS-AV: The record they are caching, but the… the truth is that they may be abused.

119
00:19:16.070 --> 00:19:17.039
MTS-AV: Times is right.

120
00:19:17.040 --> 00:19:19.480
Geoff Huston: Probably a deeper conversation, but yeah, thank you.

121
00:19:21.630 --> 00:19:23.830
MTS-AV: Sorry, Geoff, can you repeat?

122
00:19:24.350 --> 00:19:29.590
Geoff Huston: I said it's probably a deeper conversation that also touches upon.

123
00:19:29.760 --> 00:19:42.979
Geoff Huston: default certificate lifetimes, and the whole issue of whether a certificate infrastructure is a valid commentary on the current and short-term future of a domain name.

124
00:19:42.980 --> 00:19:50.000
Geoff Huston: or whether the DNS has outlived and just gone past the utility of certificates at all.

125
00:19:50.150 --> 00:19:56.369
Geoff Huston: But as I said, I think that's a deeper conversation than where we are here. It just strikes me as…

126
00:19:56.510 --> 00:20:03.370
Geoff Huston: somewhat bizarre that the response to a problem is just to shorten the lifetime.

127
00:20:03.590 --> 00:20:13.039
Geoff Huston: But when you do that, there's no endpoint. You can keep on shortening it until you get down to no lifetime at all, in which case you wonder why you're doing it.

128
00:20:16.490 --> 00:20:17.180
MTS-AV: Lauren.

129
00:20:21.140 --> 00:20:24.409
MTS-AV: Can you go back to the slide that listed the different?

130
00:20:25.130 --> 00:20:26.080
MTS-AV: times.

131
00:20:26.610 --> 00:20:27.740
MTS-AV: Back another one.

132
00:20:29.030 --> 00:20:30.050
MTS-AV: Board 1.

133
00:20:30.250 --> 00:20:37.980
MTS-AV: No, the one that had the table, the different CAs. Oh, this one. Yeah. So… For those…

134
00:20:38.700 --> 00:20:44.680
MTS-AV: Do you have anything that shows how long the validation was reused for?

135
00:20:45.840 --> 00:20:58.350
MTS-AV: Unfortunately, no. And the reason is we were unable to do this at scale because certificate logs are massive and are very hard to process. We really wanted to go back and.

136
00:20:58.480 --> 00:21:04.159
MTS-AV: Look at when it was the previous certificate issued, and basically what was the certificate issued then.

137
00:21:04.370 --> 00:21:05.220
MTS-AV: It was…

138
00:21:05.430 --> 00:21:11.019
MTS-AV: paying to do this at scale. We really want to get that number. Probably that'd be extremely interesting.

139
00:21:11.320 --> 00:21:12.840
MTS-AV: But the…

140
00:21:13.430 --> 00:21:30.249
MTS-AV: High. No, I mean, this happens at least at the level where it's not a certificate was issued like the day before and the day after you see like the validation caching reuse is a there is at least like a month or something. Okay. Because the Google CA will do a maximum of eight days. Okay.

141
00:21:30.380 --> 00:21:33.229
MTS-AV: And it seems like the numbers.

142
00:21:33.460 --> 00:21:38.579
MTS-AV: If you have a look at what people who do 390 days and 8 days, you'd see a much wider disparity.

143
00:21:39.380 --> 00:21:51.870
MTS-AV: I think if you do only each 8 days, you see here a lower number, because we do that 3 days filtering, so you already cut off some of the certificates we do cache.

144
00:21:52.430 --> 00:22:00.810
MTS-AV: That's probably why Google then shows up with lower amount per number of certificates issued compared to the others.

145
00:22:01.180 --> 00:22:03.000
MTS-AV: That may be a good, likely explanation.

146
00:22:03.750 --> 00:22:05.849
MTS-AV: Do you have these officially somewhere?

147
00:22:06.640 --> 00:22:07.390
MTS-AV: Yep.

148
00:22:10.230 --> 00:22:15.869
MTS-AV: I can try and find the actual link, but that's under the Google Cloud Security blog. Okay.

149
00:22:17.060 --> 00:22:23.190
MTS-AV: But I'm also just kind of wondering about the methodology, because it feels like some of it is not… anyway, we can chat more later.

150
00:22:29.020 --> 00:22:35.769
MTS-AV: I think we have, time for a question or two from a non-SSAC, Questioner, if we have any?

151
00:22:37.910 --> 00:22:38.670
MTS-AV: Andrew?

152
00:22:41.410 --> 00:22:42.950
MTS-AV: We got one online.

153
00:22:43.740 --> 00:22:45.320
MTS-AV: Andrew, go ahead.

154
00:22:45.810 --> 00:22:52.020
MTS-AV: Hi, Andrew Campting. Thanks for the presentation, Raphael. Very interesting.

155
00:22:52.350 --> 00:22:59.770
MTS-AV: Should we really be looking more at certificate revocation? Are we trying to solve the problem using the wrong lever?

156
00:23:02.060 --> 00:23:08.899
MTS-AV: The main issue of certificate revocation is consuming certificate revocation.

157
00:23:09.450 --> 00:23:12.790
MTS-AV: This, how do you push certificate revocation to the edge?

158
00:23:14.150 --> 00:23:17.230
MTS-AV: That has been an unsolved problem for sure. I mean.

159
00:23:17.860 --> 00:23:35.190
MTS-AV: In an ideal world, yes. In an ideal world, you don't want to have certificates dangling for domain names that are not under the control of the same person anymore, or are expired. Because that certificate would have been established on a chain of trust that is not there anymore.

160
00:23:35.630 --> 00:23:37.350
MTS-AV: In an ideal world, yes.

161
00:23:37.530 --> 00:23:39.470
MTS-AV: The practical world that may be challenging.

162
00:23:46.510 --> 00:23:47.410
MTS-AV: Who's next?

163
00:23:48.090 --> 00:23:50.699
MTS-AV: I have a comment on that. So I think,

164
00:23:50.990 --> 00:23:55.030
MTS-AV: He said the practical problem with certificate revocation is,

165
00:23:55.290 --> 00:23:58.460
MTS-AV: How to push the revocation information to the client?

166
00:23:59.000 --> 00:24:07.879
MTS-AV: And that is essentially the same question as how short you make the certificate lifetime. It's, of course, a different data structure, it's a list for all domains, sort of, that are

167
00:24:08.960 --> 00:24:12.030
MTS-AV: That have their certificates revoked, and the certificate is persitive.

168
00:24:12.270 --> 00:24:20.440
MTS-AV: It's per domain, so you have to get that in a different way. But the fundamental question that you have some sort of near real-time delivery requirement.

169
00:24:20.580 --> 00:24:24.809
MTS-AV: is the same. So I think it boils down to the same kind of problem, even

170
00:24:25.070 --> 00:24:26.630
MTS-AV: If it's structurally different.

171
00:24:26.760 --> 00:24:34.779
MTS-AV: And if we find a way to do this efficiently for certificate revocation lists, probably we also know how to do it for certificates themselves.

172
00:24:37.440 --> 00:24:47.139
MTS-AV: Yeah, I mean, a lot of things have shown revocation just doesn't work, right? Either you have massive big CRLs, or you have OSCP, which leaks huge amounts of privacy stuff and doesn't scale.

173
00:24:47.270 --> 00:24:58.220
MTS-AV: But the reason I sort of started wondering about the methodology is if you add up all of the numbers, you got to 92.8% or something. I think it was the next slide over.

174
00:25:01.390 --> 00:25:02.840
MTS-AV: Yeah, go back one.

175
00:25:04.470 --> 00:25:12.819
MTS-AV: Nope, you don't have slide numbers, unfortunately, so I didn't write them down. I think it was forward, forward, forward, forward.

176
00:25:13.400 --> 00:25:15.690
MTS-AV: So yeah, go back. You just passed it.

177
00:25:17.490 --> 00:25:18.930
MTS-AV: Nope. Next one.

178
00:25:20.280 --> 00:25:21.450
MTS-AV: Next one?

179
00:25:22.850 --> 00:25:23.950
MTS-AV: Next one.

180
00:25:24.920 --> 00:25:30.939
MTS-AV: You had a thing where you added up all of the numbers and you got 98% or 92% of.

181
00:25:31.370 --> 00:25:37.869
MTS-AV: These ones. Yes, that. So 92 point blah blah blah had cases of active delegation when they start

182
00:25:39.360 --> 00:25:49.790
MTS-AV: Yeah, so then you're claiming that there are almost 3%, or a little bit more than 3%, of certificates that were issued with no DNS working at the time? Yeah, things that…

183
00:25:49.920 --> 00:26:00.410
MTS-AV: This is an empirical evidence. It's just what you can observe from the external world. Sometimes you may have, like, certificates that have been issued for a domain name that existed less than a day.

184
00:26:00.970 --> 00:26:04.400
MTS-AV: And in that case, it's extremely hard to

185
00:26:05.130 --> 00:26:14.709
MTS-AV: find prior DNS evidence, because if it was existing for less than a day, then you have a certificate that was issued with the correct DNS evidence, but…

186
00:26:15.210 --> 00:26:21.929
MTS-AV: the domain was not in the zoom file. That that is our historical view, and that means that there was no

187
00:26:22.290 --> 00:26:26.420
MTS-AV: prior DNS evidence, according from an external observer.

188
00:26:27.020 --> 00:26:40.930
MTS-AV: I mean, it's just the quirks of the… how the… what you can observe from the outside, basically. Yeah, I mean, it's also… is it possible that you're not getting all of the DNS information that you think you are? Right? Like, you're looking in…

189
00:26:41.090 --> 00:26:42.610
MTS-AV: Some of these are.

190
00:26:43.280 --> 00:26:44.250
MTS-AV: like it's

191
00:26:44.290 --> 00:27:03.370
MTS-AV: It's unclear where you got all the, does the domain exist information from. I'm guessing some of the CZDS? CZDS zone file. Yeah, it's daily CZDS zone file. Okay, so if the CZDS file hasn't updated, because sometimes that happens, that could push it over. Sometimes they don't update for a couple of weeks. Okay. Yeah, so that case is a little mixed, basically.

192
00:27:07.310 --> 00:27:10.979
MTS-AV: Hey, Kathy, is there anybody else in the queue? No.

193
00:27:11.090 --> 00:27:12.920
MTS-AV: Okay, thanks, Rafaela.

194
00:27:15.570 --> 00:27:16.560
MTS-AV: Thank you.

195
00:27:17.240 --> 00:27:18.150
MTS-AV: Peter.

196
00:27:19.880 --> 00:27:24.009
MTS-AV: Thank you. I think Kathy's gonna share the slides until I get to the demo.

197
00:27:25.210 --> 00:27:33.300
MTS-AV: All right, so, DNSSAC timeline for TLDs sounds boring, but I'm not aware of any, Public.

198
00:27:34.760 --> 00:27:41.799
MTS-AV: timeline that, gets updated every day or something. So, yeah, this is about this topic. Next slide, please.

199
00:27:41.910 --> 00:27:48.810
MTS-AV: Recently, my colleague Barbara was writing an article about common beliefs about DNSSEC put to the test.

200
00:27:48.960 --> 00:27:52.870
MTS-AV: It's been published on Tuesday, and some of those people here in the room have endorsed this.

201
00:27:53.080 --> 00:27:55.710
MTS-AV: And, overall, roughly 60.

202
00:27:56.070 --> 00:28:00.170
MTS-AV: And, we tried to, look at some…

203
00:28:00.330 --> 00:28:12.689
MTS-AV: of the opinions and facts, or maybe non-facts circulating about DNSSEC and checking them against reality. So, for example, how much it's government-controlled, or whether it's cryptographically weak.

204
00:28:13.110 --> 00:28:17.130
MTS-AV: And so, at the time, we were looking for data, and, we…

205
00:28:17.450 --> 00:28:22.170
MTS-AV: found various things, Victor Duchovny's, and Wes Hardiker's DNSIC tools, for example.

206
00:28:22.300 --> 00:28:24.770
MTS-AV: But we didn't find such a DNSSEC,

207
00:28:24.890 --> 00:28:27.600
MTS-AV: TLD timeline, so that's what motivated this.

208
00:28:27.740 --> 00:28:31.980
MTS-AV: When we were drafting the article in June, All right, next slide.

209
00:28:32.880 --> 00:28:42.259
MTS-AV: So here's, the other stuff that we found. There's the IANIX outage list, which is well known. It is a curated list of ENSAC, cost.

210
00:28:42.660 --> 00:28:45.770
MTS-AV: Validation or resolution outages, and

211
00:28:46.220 --> 00:29:00.270
MTS-AV: Yeah, it's, there's a lot of incidents from the past, and recently there's less. It's unclear why that is. Then there's the ones from Victor and Wes that I just mentioned, and there is also, a presentation from just yesterday by John Christoph at VeriSign.

212
00:29:00.310 --> 00:29:12.759
MTS-AV: He presented at PLNOG yesterday, and they did, I think, a SACSpider-based measurement of DNSSEC availability according to some weighting, and they came up with a very high availability. Unfortunately, the slides aren't online yet, at least as of yesterday.

213
00:29:12.910 --> 00:29:17.759
MTS-AV: I'm looking very much forward to what exactly they did to figure that out.

214
00:29:18.150 --> 00:29:26.320
MTS-AV: But still, we didn't find this DNSSEC timeline, so we built that, and, it does, An open record of…

215
00:29:26.470 --> 00:29:31.440
MTS-AV: Essentially, what the status of… TLDs is every day with respect to DNSSEC.

216
00:29:32.040 --> 00:29:33.300
MTS-AV: Next slide.

217
00:29:33.970 --> 00:29:34.710
MTS-AV: Hmm.

218
00:29:35.950 --> 00:29:44.490
MTS-AV: So what do we do? Every day in a GitHub action, we fetch the root zone and look at all the TLDs.

219
00:29:44.710 --> 00:29:54.389
MTS-AV: Then we query the TLD's SOA record using a local unbound that's in a Docker container. It's configured to do, its own validation, it supports ETE.

220
00:29:54.500 --> 00:30:05.829
MTS-AV: And, we then look at whether the AD bit was, set in the response… the unbound resolver's response. We record all kinds of… all kinds of other response details, like the R code and EDE, so that…

221
00:30:05.930 --> 00:30:20.450
MTS-AV: If we have a classification bug, for example, we can reclassify later based on what the response actually said. And then we transform this into a JSON that gets pushed into a web app on GitHub pages. And so there is no separate infrastructure that we operate for this.

222
00:30:20.610 --> 00:30:26.789
MTS-AV: And the web app, has various user interface widgets to slice and dice the data. We'll get to that in the demo.

223
00:30:27.830 --> 00:30:30.920
MTS-AV: Yeah, so there is,

224
00:30:31.410 --> 00:30:36.349
MTS-AV: Categories by GTLD and CCTLD, and by IDN and non-IDN, and various other

225
00:30:36.810 --> 00:30:48.289
MTS-AV: things, and yeah, so one fun fact is, at the bottom right, you see the diagram of, GitHub Action runtime delay after it was scheduled, so it's scheduled every day at 3.30 UTC.

226
00:30:48.300 --> 00:30:57.370
MTS-AV: And usually, it starts, like, half an hour later, or two hours, or something. In the worst case, it starts half a day later. We don't really care, it's still once a day, but it's just an interesting.

227
00:30:57.520 --> 00:30:58.999
MTS-AV: Side insight, I think.

228
00:31:00.190 --> 00:31:04.660
MTS-AV: All right. We started doing this in June.

229
00:31:05.110 --> 00:31:06.090
MTS-AV: Next slide.

230
00:31:07.320 --> 00:31:15.749
MTS-AV: So there's different statuses that come out of the classification. Secure is, you know, DNSSEC works fine. Insecure is when the TLD

231
00:31:15.880 --> 00:31:23.710
MTS-AV: doesn't have a DS record, or has a DS record whose algorithm is unsupported, but that is currently not the case for any TLD.

232
00:31:24.040 --> 00:31:35.099
MTS-AV: There is BOGUS when DNSSEC validation failed, and we record the EDE, extended DNS error codes, that indicate what exactly went wrong. The unbound resolver returns this, and

233
00:31:35.690 --> 00:31:40.350
MTS-AV: Candidate errors are, like, signature expiration, or missing keys, and stuff like that.

234
00:31:40.760 --> 00:31:46.660
MTS-AV: There's unreachable, which is when we don't get an answer. Of course, this could also be because our,

235
00:31:47.010 --> 00:31:52.150
MTS-AV: Runner is, disconnected for some reason, so we do multiple attempts, and we only

236
00:31:52.350 --> 00:31:58.159
MTS-AV: use this verdict if we confirm that we can actually talk to the root, but not to the TLE.

237
00:31:58.630 --> 00:32:08.799
MTS-AV: And otherwise, we classify it as, unmeasured, which is error. And the error category normally is hidden in the display, because it's not an interesting.

238
00:32:08.960 --> 00:32:13.950
MTS-AV: insight about DNSSEC configuration, it's more like a measurement artifact if something is an error.

239
00:32:15.400 --> 00:32:17.839
MTS-AV: Okay, next slide.

240
00:32:20.590 --> 00:32:30.479
MTS-AV: Yeah, so here's, a bit more about what we do, for unreachable. So when there is no response, we try again 2 minutes later, and we process other TLDs in the meantime.

241
00:32:30.830 --> 00:32:34.110
MTS-AV: And then we check whether we can actually talk to the root service, which…

242
00:32:34.370 --> 00:32:43.029
MTS-AV: Probably we can if we, process other TLEs in the meantime, but there is no communication between the different threads, so we just, you know, check the route anyway.

243
00:32:43.170 --> 00:32:54.310
MTS-AV: Because there's no awareness, so to speak. And if we can talk to the root, but not to the TLD's name service, then we do unreachable. We also record unreachable if the unbound resolver itself

244
00:32:54.420 --> 00:33:00.739
MTS-AV: Returns that, that can happen, for example, when, none of the IP addresses of the name servers.

245
00:33:00.970 --> 00:33:05.539
MTS-AV: actually are reachable, but I mean, the IP addresses could be fetched, but they don't respond.

246
00:33:06.050 --> 00:33:07.770
MTS-AV: Hmm.

247
00:33:07.970 --> 00:33:15.949
MTS-AV: Yeah, so this, was a bit of engineering, not very complicated, but still, we didn't immediately see it was necessary.

248
00:33:16.060 --> 00:33:19.219
MTS-AV: It did become necessary, because once we.

249
00:33:19.390 --> 00:33:22.430
MTS-AV: You know, before we had that, there were,

250
00:33:22.570 --> 00:33:34.490
MTS-AV: time windows within the measurement of a few seconds where there were connectivity issues for some reason. It's probably some rate limits that, you know, for outgoing DNS queries on GitHub runners, or I don't know.

251
00:33:34.730 --> 00:33:37.170
MTS-AV: But we had stretches of,

252
00:33:37.390 --> 00:33:47.280
MTS-AV: of sequential TLDs that were, you know, we processed them alphabetically, and there were sequences of, like, 3 or 5 or something that would, together.

253
00:33:47.890 --> 00:33:53.649
MTS-AV: appear unreachable even though they were operated by different people. And that seemed implausible, so we thought it…

254
00:33:53.960 --> 00:33:57.939
MTS-AV: Probably is some measurement issue, and it turned out to go away if we do this.

255
00:33:58.540 --> 00:34:05.160
MTS-AV: It's not really clear, I wasn't able to find any documentation about GitHub rate limits, on this.

256
00:34:05.410 --> 00:34:10.589
MTS-AV: sort of thing. And it seemed, like, random. I mean, it's… we do a few thousand queries, and then…

257
00:34:10.949 --> 00:34:13.790
MTS-AV: Even if we slowed it down, it didn't go away, so I don't know.

258
00:34:14.610 --> 00:34:16.969
MTS-AV: Next slide, please.

259
00:34:17.690 --> 00:34:26.290
MTS-AV: All right, so at the top is, the timeline, so to speak. I mean, not the results yet. We are the yellow part on the right.

260
00:34:26.630 --> 00:34:34.859
MTS-AV: from June 20… sorry, June 17 this year until today. All the other data from 2012 on is from Jaap Akerhus.

261
00:34:35.010 --> 00:34:49.219
MTS-AV: Who used to be in the SSAC, and he has a similar system that, runs on his private equipment, or maybe an LNET lab's equipment, I don't know, but anyway. It's not a publicly available, thing. He presented that at ICANN55.

262
00:34:49.409 --> 00:34:55.739
MTS-AV: And, he handed over his data to us, and, we included that in our displays, so we have

263
00:34:55.850 --> 00:34:58.790
MTS-AV: data from back in 2012 until now.

264
00:34:58.990 --> 00:35:00.520
MTS-AV: And, there were some

265
00:35:00.870 --> 00:35:15.019
MTS-AV: format conversions. He also does two measurements a day, and not just one. And he only looked at records, sorry, at DLDs that had a DS record, where we also started looking at insecure domains, so that you can have nice graphs about that, too.

266
00:35:15.170 --> 00:35:18.789
MTS-AV: Anyway, so there was some sort of adoption necessary.

267
00:35:19.310 --> 00:35:20.200
MTS-AV: M.

268
00:35:20.500 --> 00:35:29.240
MTS-AV: We started including insecure domains in August only because we noticed we would like to have these graphs. And we don't have any insecure historic data.

269
00:35:29.490 --> 00:35:38.340
MTS-AV: But I think it can probably be reconstructed from historic zone files from the root, so we might import that later so that the graph doesn't jump.

270
00:35:40.000 --> 00:35:41.520
MTS-AV: Next slide.

271
00:35:41.650 --> 00:35:45.419
MTS-AV: All right, so it's demo time. I will switch to…

272
00:35:46.300 --> 00:35:48.800
MTS-AV: Good luck, yeah. I mean, it all depends on GitHub.

273
00:35:50.390 --> 00:35:54.320
MTS-AV: Anyway, so I will share my screen, and then I hope I don't mess up.

274
00:35:54.980 --> 00:35:59.090
MTS-AV: What I'm doing…

275
00:36:00.440 --> 00:36:01.500
MTS-AV: Dip, do, do, do, do.

276
00:36:03.640 --> 00:36:04.910
MTS-AV: Give me one second.

277
00:36:07.970 --> 00:36:12.209
MTS-AV: I think I wanted to show one more slide, actually, but I will show it on my own machine.

278
00:36:14.310 --> 00:36:22.689
MTS-AV: Okay, so this is, essentially the display that the website gives, except that it's sliced yearly, which the website doesn't…

279
00:36:22.800 --> 00:36:35.939
MTS-AV: do, and this is, easier to digest, so I will start with this. This shows, how signing grew. You can see that in 2012, this is always January 1st, there were just a few under 100

280
00:36:36.460 --> 00:36:40.680
MTS-AV: TLDs that were assigned and most of them were CC TLDs.

281
00:36:40.810 --> 00:36:49.499
MTS-AV: And, I don't know how many, maybe 50. There's now roughly 170, I think, signed CCTLEs, or 150.

282
00:36:49.670 --> 00:36:58.580
MTS-AV: And they were by far overtaken by the GTLDs, of course, because of the 2012 round, which got things delegated around 2016.

283
00:36:58.700 --> 00:37:03.950
MTS-AV: And you can see that the maximum is in 2018, and after that, a bunch of brand TLDs died.

284
00:37:04.070 --> 00:37:06.080
MTS-AV: So it went down.

285
00:37:07.110 --> 00:37:13.449
MTS-AV: And yeah, so that's the general behavior. And then in the middle of it, there is the IDNs, which are a small fraction.

286
00:37:16.380 --> 00:37:17.240
MTS-AV: Okay.

287
00:37:18.860 --> 00:37:21.760
MTS-AV: So… Here.

288
00:37:22.230 --> 00:37:28.650
MTS-AV: So this is our beautiful GitHub URL. We might actually —

289
00:37:28.880 --> 00:37:31.310
MTS-AV: Switch to a nicer domain at some point.

290
00:37:31.620 --> 00:37:37.710
MTS-AV: Let me… Pull up my notes, what I wanted to show. So how signing grew is essentially,

291
00:37:38.170 --> 00:37:45.610
MTS-AV: The absolute counts, you can have absolute counts here. Otherwise, you have log scale — sorry, percentage counts. When you load the page.

292
00:37:45.860 --> 00:37:48.710
MTS-AV: The percentage count actually zooms in.

293
00:37:48.940 --> 00:37:55.330
MTS-AV: Because otherwise, you wouldn't be able to see anything. If you go to 100% here…

294
00:37:57.630 --> 00:38:01.610
MTS-AV: Right? Then, the failures are down here. It's not very useful.

295
00:38:01.820 --> 00:38:06.509
MTS-AV: So we use percentage display by default, but we zoom in, and the top is roughly 3%.

296
00:38:06.650 --> 00:38:09.930
MTS-AV: In the beginning, the failure rate was quite high.

297
00:38:10.170 --> 00:38:11.360
MTS-AV: Which,

298
00:38:11.890 --> 00:38:23.030
MTS-AV: improved over time, but the main reason for that is that there is a lot of GTLDs now which are required to operate the UNSAC in a solid way, and they are the large majority of the green.

299
00:38:23.910 --> 00:38:26.549
MTS-AV: Okay, what else did I want to show?

300
00:38:27.740 --> 00:38:37.339
MTS-AV: Yeah, so the absolute counts are essentially what we just saw in the other slide, but they are in logarithmic scale, because otherwise you would not be able to see the small numbers at all. So each.

301
00:38:37.790 --> 00:38:40.880
MTS-AV: Tick here on the y-axis is a factor of 10.

302
00:38:41.530 --> 00:38:46.620
MTS-AV: And that's why it looks a little skewed, but actually, it's sort of magnifying the bottom part of it.

303
00:38:48.300 --> 00:38:53.330
MTS-AV: You can also see that there are some measurement errors.

304
00:38:54.130 --> 00:39:02.950
MTS-AV: The… Double click to reset. Oh, okay. So, the measurement errors are usually

305
00:39:03.160 --> 00:39:07.950
MTS-AV: Not displayed, so if we add them… We get in 2021.

306
00:39:08.370 --> 00:39:13.649
MTS-AV: 2… Days where there were measurement errors.

307
00:39:13.940 --> 00:39:20.710
MTS-AV: Roughly 50% of the measurements failed. This is from YARP's historic data. There was some connection issue or what, I don't know.

308
00:39:21.030 --> 00:39:21.980
MTS-AV: And…

309
00:39:22.140 --> 00:39:28.979
MTS-AV: yeah, we figured it's best to keep them in the data set, but don't display them by default. I don't think we can retroactively fix it.

310
00:39:30.150 --> 00:39:35.679
MTS-AV: And so, if you… Go to percentage display and ignore them, then,

311
00:39:37.760 --> 00:39:38.910
MTS-AV: Then you will not see them.

312
00:39:40.290 --> 00:39:41.010
MTS-AV: Yeah.

313
00:39:41.720 --> 00:39:46.070
MTS-AV: Well, oh, in fact, you do, because percentage is, to the full number.

314
00:39:46.840 --> 00:39:53.090
MTS-AV: Okay, alright, then let's reload this to go back to the… initial display.

315
00:39:53.350 --> 00:40:04.879
MTS-AV: I want to, share one specific day, January 3rd, 2020, so we can, go here. So, first of all, you see, for any day, what's happening. There is, like, on this day.

316
00:40:04.960 --> 00:40:15.850
MTS-AV: July 13th, 2017, there were 1,394 secure TLDs and two bogus ones, which is 0.1%, and so we can now drag, here in the.

317
00:40:16.420 --> 00:40:17.460
MTS-AV: Dataset?

318
00:40:18.330 --> 00:40:19.430
MTS-AV: And zoom in.

319
00:40:20.130 --> 00:40:22.539
MTS-AV: And ignore the secure ones, and then you see…

320
00:40:22.660 --> 00:40:27.289
MTS-AV: that on the 3rd of January, the number of bogus domains went from 2 to 8.

321
00:40:27.500 --> 00:40:32.900
MTS-AV: And so you can click on that, and then you get the day detail at the bottom.

322
00:40:33.500 --> 00:40:36.400
MTS-AV: Okay, so the… Green stuff is hidden.

323
00:40:36.730 --> 00:40:41.940
MTS-AV: And what we have here are the bogus ones. Those are all IDNs from India?

324
00:40:42.310 --> 00:40:45.820
MTS-AV: And, they all had signature expiration.

325
00:40:46.280 --> 00:40:53.600
MTS-AV: going on, so the EDE code was 7, and you can see here, signature expired. And you see which IP address the response came from.

326
00:40:53.860 --> 00:40:55.189
MTS-AV: And there's,

327
00:40:56.940 --> 00:41:02.369
MTS-AV: a null number of Ds records, because I think the data from Yap didn't record that number.

328
00:41:02.610 --> 00:41:06.070
MTS-AV: I think we record since June how many DS records there are.

329
00:41:06.480 --> 00:41:09.990
MTS-AV: Anyway, so these are the ends.

330
00:41:10.430 --> 00:41:18.399
MTS-AV: were new IDNs from new scripts, and they were from the 2017 batch, and not open for registration. So apparently it was testing.

331
00:41:18.790 --> 00:41:21.590
MTS-AV: And India had older IDNs before that.

332
00:41:21.750 --> 00:41:25.210
MTS-AV: And they stayed secure, so they did not have an issue.

333
00:41:25.520 --> 00:41:31.320
MTS-AV: And they also have the .in domain, obviously, and that also did not have an issue. So this is not really a production outage.

334
00:41:31.700 --> 00:41:37.039
MTS-AV: It is more like, an easily visible… Testing artifact, it seems.

335
00:41:37.270 --> 00:41:39.590
MTS-AV: And then after 5 days, that went away again.

336
00:41:40.490 --> 00:41:45.690
MTS-AV: You can also, I don't know which day this is, I selected a random day.

337
00:41:47.460 --> 00:41:55.099
MTS-AV: You can see here, like, when you… Mouse over… Which of the things, or what status?

338
00:41:55.240 --> 00:42:00.469
MTS-AV: And then when you click on it, maybe let's here, click on this… Click on one of them.

339
00:42:02.070 --> 00:42:06.829
MTS-AV: Line highlights, so when the… List is longer, it's closer to that position.

340
00:42:10.680 --> 00:42:16.960
MTS-AV: Okay, so let's look at another story. There is the… Country of Jordan.

341
00:42:17.760 --> 00:42:19.319
MTS-AV: They have an IDN.

342
00:42:19.470 --> 00:42:27.070
MTS-AV: So you can filter by IDN. So you can add one or more or even other TLDs. Xn dash dash.

343
00:42:27.890 --> 00:42:30.830
MTS-AV: MGBAYH.

344
00:42:31.570 --> 00:42:38.149
MTS-AV: 7GPA. Can anyone do that, like, in their minds? Like, some people can do hex.

345
00:42:38.270 --> 00:42:40.209
MTS-AV: But does anyone do puny code?

346
00:42:40.470 --> 00:42:42.379
MTS-AV: Anyway, so you can filter by that.

347
00:42:42.690 --> 00:42:48.350
MTS-AV: And then you can see that this CCTLD was introduced in 2023.

348
00:42:48.810 --> 00:42:52.149
MTS-AV: And that most of the time it has been bogus, and

349
00:42:52.700 --> 00:42:58.219
MTS-AV: Yeah, so that's really weird. But also it seems like nobody's really using that.

350
00:42:58.350 --> 00:43:04.269
MTS-AV: Because if people were using that, then it would… failed pretty hard.

351
00:43:04.720 --> 00:43:08.560
MTS-AV: Hum… Yeah, so this is from…

352
00:43:08.870 --> 00:43:12.029
MTS-AV: I guess what we measured, roughly this period.

353
00:43:12.850 --> 00:43:14.910
MTS-AV: And before that, it was YARPS data.

354
00:43:15.440 --> 00:43:23.970
MTS-AV: And, the interesting thing is that.jo, which is the Jordan ASCII TLD, It's not even signed.

355
00:43:24.440 --> 00:43:34.789
MTS-AV: So the IDN variant is signed but broken, and the non-IDN variant is not signed. So, it doesn't seem like they're really into doing DDNSSEC so far.

356
00:43:34.950 --> 00:43:39.020
MTS-AV: And I would also suggest that that is probably testing.

357
00:43:39.290 --> 00:43:45.220
MTS-AV: So that raises the question whether ccTLDs are different when it comes to IDNs and DNSSEC.

358
00:43:45.600 --> 00:43:50.600
MTS-AV: So that, gets us to a different selector, so we can look at,

359
00:43:50.800 --> 00:43:52.130
MTS-AV: How do we do this?

360
00:43:52.710 --> 00:44:02.990
MTS-AV: Absolute numbers may be… And, only bogus… And… Dip, dip.

361
00:44:03.940 --> 00:44:11.010
MTS-AV: Let's see, let's compare… Well, the GTLDs, they… So maybe…

362
00:44:11.310 --> 00:44:18.240
MTS-AV: I want to look at the GTLD. So, that's a very small number of failures, and if you only look at the ASCII variants.

363
00:44:19.110 --> 00:44:20.620
MTS-AV: IDNs, okay.

364
00:44:21.240 --> 00:44:25.590
MTS-AV: Anyway, so if you look at… whoops, I didn't know that disappears completely.

365
00:44:26.210 --> 00:44:30.559
MTS-AV: The CCT LD ASCII versions.

366
00:44:30.690 --> 00:44:33.359
MTS-AV: On some days, have one failure, or two.

367
00:44:33.510 --> 00:44:35.189
MTS-AV: On one day, which is,

368
00:44:36.970 --> 00:44:39.509
MTS-AV: June, 2 years ago. June 11.

369
00:44:39.660 --> 00:44:42.079
MTS-AV: If you look at the IDN variants of it.

370
00:44:43.710 --> 00:44:49.910
MTS-AV: They have longer stretches of that, and sometimes more in one day. This is the India thing that we just looked at.

371
00:44:50.220 --> 00:44:56.600
MTS-AV: And you have to consider that the CCTLD IDNs are only

372
00:44:58.930 --> 00:45:15.370
MTS-AV: Yeah, 3% of signed TLDs are IDNs, CCTLDs, so 1 30th of the signed TLDs are CCTLD IDNs, but they make up for 80% of all the bogus events in this database since 2012, and they make up 100% of them since we started taking over the measurement.

373
00:45:15.630 --> 00:45:20.179
MTS-AV: So that really suggests that CCTLD IDNs, for some reason.

374
00:45:20.300 --> 00:45:26.020
MTS-AV: Are not as solidly maintained in regards of DNSSEC stability.

375
00:45:27.860 --> 00:45:33.049
MTS-AV: All right. And then finally, we can look at who is still unsigned.

376
00:45:33.200 --> 00:45:39.250
MTS-AV: So, we can do insecure. We just started adding that in… Umm.

377
00:45:39.670 --> 00:45:43.630
MTS-AV: August, so there is, like, a jump here, and we might backfill the other stuff.

378
00:45:43.880 --> 00:45:50.559
MTS-AV: So we can select that, and then we can look at any random day here, and we can go down, and we see the list.

379
00:45:51.280 --> 00:45:59.640
MTS-AV: And, so those are currently still insecure. Those, I think, are 15 IDNs, and the rest of them, like, 71 or something.

380
00:45:59.790 --> 00:46:06.299
MTS-AV: Our ASCII ccTLDs and all the gTLDs, however, are secure, because that's mandated.

381
00:46:08.410 --> 00:46:12.719
MTS-AV: Okay. Recently signed were Dot DJ, which is, I think, a nice.

382
00:46:12.820 --> 00:46:13.680
MTS-AV: Suffix?

383
00:46:13.920 --> 00:46:16.430
MTS-AV: and also Pk, Pakistan.

384
00:46:17.560 --> 00:46:22.860
MTS-AV: I'll hand it back to… Kathy, after this demo…

385
00:46:27.960 --> 00:46:31.849
MTS-AV: Okay, you can skip, like, a few slides, this is in case the demo wouldn't work.

386
00:46:32.550 --> 00:46:41.370
MTS-AV: Yeah, exactly. So here we are. And so what can't the timeline show? So we have, for example, the outage of DOT DE in May this year.

387
00:46:41.490 --> 00:46:50.250
MTS-AV: This was still when Jaap's measurements were what fed our database, and he has runs in UTC time in the morning at 6 and at 6 PM.

388
00:46:50.450 --> 00:47:03.999
MTS-AV: And the DE outage was, between those windows. So, the 3-hour disruption was not visible, and that's why it isn't there. So you can't really use this timeline to spot Every outage is more like a trend indicator or something like that.

389
00:47:04.180 --> 00:47:11.209
MTS-AV: And, yeah, so even if his run had been there, there's a chance of not spotting it, because not everything was wrong.

390
00:47:11.530 --> 00:47:14.610
MTS-AV: So, some stuff did actually work.

391
00:47:14.930 --> 00:47:25.170
MTS-AV: And also, it's a quite limited view, right? There's the GitHub, restriction, you know, whatever they have in their environment might affect the measurement. It's only one vantage point, it's one resolver.

392
00:47:25.460 --> 00:47:32.760
MTS-AV: And yeah, so it's good as a base indicator of stuff, but it's not — something to…

393
00:47:33.390 --> 00:47:36.379
MTS-AV: Objectively tell whether something is really the case or not.

394
00:47:36.820 --> 00:47:37.610
MTS-AV: Globally.

395
00:47:38.110 --> 00:47:39.620
MTS-AV: All right, next slide.

396
00:47:40.420 --> 00:47:43.300
MTS-AV: So that's, the final slide.

397
00:47:43.830 --> 00:48:00.789
MTS-AV: The code is open source, it's on GitHub here. Everybody, every TLD or people elsewhere can look up their data. I don't know if you spotted that during the demo, but the address bar actually changes as you select things and different filters, so you can click on these things that are appended in the.

398
00:48:01.490 --> 00:48:08.500
MTS-AV: The URL bar, if you look at the PDF file here, or even when you found a nice display for something, you could just share it with somebody else.

399
00:48:08.840 --> 00:48:14.410
MTS-AV: And yeah, thanks again to Jaap for sharing the data with us and happy to take any questions.

400
00:48:17.480 --> 00:48:18.520
MTS-AV: Warren.

401
00:48:19.410 --> 00:48:22.969
MTS-AV: So first off, thank you. This was awesome. Really, really good work.

402
00:48:23.080 --> 00:48:36.280
MTS-AV: But as you noted, you can't really use it as an outage detector, because you do a single… How hard would it be, and how resource-intensive would it be to run this every, like, 2 or 3 minutes? Like, how much hardware would you need?

403
00:48:38.160 --> 00:48:40.820
MTS-AV: I don't think you would need very much hardware, so,

404
00:48:41.430 --> 00:48:47.370
MTS-AV: Jaap's measurements ran for 20 minutes and ours run between 6 and 16 minutes.

405
00:48:47.640 --> 00:48:53.650
MTS-AV: Our main uncertainty is when they run, because the GitHub scheduling, but that could be fixed with an internal.

406
00:48:53.930 --> 00:49:04.060
MTS-AV: So, with an external trigger. And also, it doesn't have to run on GitHub, right? There is other ways of running it. And if we did some, better optimization of.

407
00:49:04.250 --> 00:49:15.739
MTS-AV: how the concurrent requests are done, or maybe shuffled the order to evade rate limits or whatever, then probably the runtime could, be reduced without introducing failure. So I think once every 10 minutes probably is realistic.

408
00:49:16.060 --> 00:49:20.580
MTS-AV: We haven't looked into it because we,

409
00:49:20.740 --> 00:49:24.019
MTS-AV: Mainly started from making Jaap's thing public, sort of.

410
00:49:24.310 --> 00:49:28.359
MTS-AV: But there are certainly opportunities to change that.

411
00:49:29.170 --> 00:49:33.489
MTS-AV: Are you suggesting to donate hardware? Yeah, possibly. Okay, cool.

412
00:49:39.130 --> 00:49:41.119
MTS-AV: Mary, I don't have no further questions.

413
00:49:44.690 --> 00:49:48.149
MTS-AV: Any questions from outside of SSAC are welcome.

414
00:49:57.750 --> 00:50:01.839
MTS-AV: Okay, we, I guess we give you all 25 minutes back?

415
00:50:03.020 --> 00:50:10.220
MTS-AV: Thank you all for coming, and we have another lightning talk session coming up in a couple of days, so come back for that.

416
00:50:10.800 --> 00:50:11.720
MTS-AV: Thanks, Peter.

417
00:50:15.520 --> 00:50:17.269
MTS-AV: Scott, please stop the recording.