27th October 2026.
Side room. 4pm. Security working group.
BRIAN NISBET: OK. Hello, hello. I hope we are all very well. And excited, eager! Revving to go for the RIPE 93 security working group session, I am one of the co‑chairs, Brian Nisbet, Marcus is online and Tobias unfortunately can't join us for this meeting.
But there are definitely three co‑chairs so if you are looking to get in contact with us, security‑wg‑chair@ripe.net is the only way to fly.
Thank you to the NCC staff and chat monitoring in the absence of other physical chairs for me. We obviously have our wonderful stenographer who will record every word you say for posterity or something else entirely.
Participation is possible physically and indeed via Meetecho and we have at least one speaker coming in via Meetecho, just whether you are speaking physically in the room or writing a question in Meetecho and if you are please use the Q&A function in Meetecho, not just typing it into chat.
But either way your name and some manner of class of affiliation is necessary before you make any comments, ask any questions, etc, etc so any of this.
As with all working group sessions and everything that the RIPE community does, there's a Code of Conduct and this working group is under it as is our mailing list and you do need to report to the Code of Conduct team, there's lots of information on the RIPE 93 website and and the building in Sofia on how to do so.
And hopefully you won't be blinded by all of the lights in this hotel. So many lights.
I hope there's no star gazers who used to live near to this hotel, it's the night time is quite impressive.
You can also rate the talks on Pretalx which is no longer really a new meeting system at this point in time, this is our second meeting fully using it. You don't have to rate them. The working group is different to the plenary but it is useful informs and it's a useful way of getting feedback, you can also just email the chairs on things.
We circulated minutes from RIPE 92 and I am going to remember the say the NCC announcement in just in a moment, we approved the minutes from RIPE 92, we distributed them on the mailing list, draft, there were no notable comments, if nobody says anything in the room, then we will take them as approved.
No one seems to be rush mic, I am sure you read them at least three times, they are noted as approved. I should have read these notes out first before I finalised the agenda, voting is now open for the PC elections, we have three candidates, please do look at that and vote because the plenary content is very important and we want the community to obviously to put the people on PC who will bring the appropriate content.
There is a session on diversity, equity and inclusion in tech today in the main room at 1800. So please do remember that, after your long day of other things.
And tonight's networking event, there are buses and they will depart the entrance to this hotel at 2020 and 2030, there is a short walk after the drop off and return buses will operate every 30 minutes between 22.45 and 10
100, please remember to bring your badge.
For the agenda, are there any other agenda items people suddenly wish us to put on the agenda?
Again hearing nothing, then we shall move on to our first presentation. Bring up the title slide for that, yes, I'd like to ask Matteo Liberato to come talk to us about a longitudinal measurement study of the.kids TLD. Thank you.
MATTEO LIBERATO: Thank you the introduction. Good afternoon, my name is Mateo Liberato and I am a fourth‑year PhD student. My research in general is about the topic of childrens safety online and today I will talk to you about my research on the .kids TLD.
So, in the initial part of my research, I investigated the performance of devices such as parental control, DNS and the differences between policies and actual data gathering but this is examining the security of the internet in general and the position for children, we decided after that to examine spaces that were created explicitly to be safe for children, places that had a mandate and we have a perfect candidate for that. The .kids TLD.
.kids was created for this purpose. It's part of the general TLD programme from ICANN that the community TLDs that allow to create TLDs with a purpose. And this purpose must be defined inside some rules and in particular the .kids one establish explicitly that all the content must refer to things that are appropriate for children, so no pornography e, no violent content, no alcohol, no gambling and so forth and with this basis the .kids TLD was born in to 2022. This registry agreement also includes the removal and suspension and deletion of infringing domains.
So, this is how we approached it. We started with data gathering, we started from the open Intel data. Open Intel, it's an active DNS measurement platform that resolves every domain globally every day and that gives us a good idea of the presence of the .kids TLD online, we integrated with this data from ICANN transaction reports which provides us with registration, renewal and deletions data, that we can use as a ground to consolidate the data we measure ourselves.
These two pieces we launched that we used our our analysis from May to 22 to March of 2026.
We also added other external sources, the virus total which provides information about malicious and suspicious URLs inside of the zone, we use Cloudflare data for content categorisation, internet NL which is a platform that measured the security best practices of a domain and tells us about things like the user of RPKI, IPv6, DNSSEC.
We used several block lists to see whether .kids appeared inside these list of dangerous domains and whether they were removed eventually and finally Tranco which is a popularity ranking to see whether .kids was actually getting active use.
And this gives us the dimension of our analyses when we can see the registration dynamics, we can see how it's used, whether it's active or just left as it is, what kind of content we find inside, whether that content constitutes abuse and should be removed or not and finally how much, how popular the .kids TLD in general is.
So, let's start with the registration. .kids at the time of registry was over 6,000 domains, that growth was not natural, gradual growth that you would like. It starts very slowly, in May 2022, it's when we see the first domains in our DNS data and up until, there is a small event of growth in July of 2022 but the real event is in November, November 2022, it's a day in which in a single day we have 800 registrations, how we did some analysis and we see the vast majority of either defensive registrations so, for example, big platforms like eBay or Amazon that register a .kids domain just to have a presence in there. Or we saw parking and speculative registrations, place holders and parking domains. And in particular we also see that 85% of these registrations are just in the minimum one year term that was necessary to be able to join on the platform.
And that single day of growth constitutes one‑eighth entire zone of .kids.
So, as I mentioned before, a lot of the registration in November 2022 were parking or speculative registrations. You can see the initial black peak in this graph, it uses various lines to represent various kinds of speculative registration such as place holder and finally the black line is the sum of all of them.
As you can see, at the initial registration peak, it reaches almost 50%. In November 2022, half of the domains in this zone are speculative registration, but over time they gradually flatten, particularly you can see the anniversary of the first registration, the first growth event at the end of 2023 was the black line plummets, that's where a lot of those initial registration simply were failed to be renewed so they disappeared from the zone.
But still this is a big slice of the gTLD, if we add to this the fact that through an HTTP and HTTPS probe, we went looking for what domains were actually active and responding and what domains actually having been registered served as an IP and served content and we saw that around 18% did not.
So combining these two slices we obtain that over 30% of the .kids gTLD is a never active at any point during its existence, it's just registered and left there.
So, we saw the registration domain, we saw the user domain, let's see the content of domains.
The specification 12 as I mentioned before which is the rule that says that .kids domain must contain content that is appropriate for children, applies not only to the domain content, but also to the domain name.
So even inside of the domain name, not referring to any pornography, alcohol and gambling for example, we saw just by reading the list of registered domains that at the time of measurement, 180 domains were certainly in violation of the registration agreement that they had signed because they were domains such as galaxy bet .kids, bet live .kids and things like that, that's an active domain I saw while doing the measurement, it's southeast Asian gambling domain and we found 180 of these, 105 were gambling related and that 19 and had sexual reference inside, we also found a number of domains that contained joking or definitely inappropriate names such as Jeffrey Eptstein .kids which are definitely not supposed to be inside of this. But yes, this gives us a view of the fact that harmful content definitely existed inside of this area.
In particular also we saw that 3.7% of the domains were flagged by virus total. So they evidence actively maliciously content and phishing and scamming seemed to be the most prevalent one.
And we saw that inside of Cloudflare, we found 62 inappropriate domains according to Cloudflare specification but only 14% were classified by them.
Which, while not giving us a complete picture of what's inside these gTLDs tells us that the fact that Cloudflare itself failed to classify it, it's probably a signal that this gTLD doesn't see much use, there was not much traffic that could lead to a classification.
Finally we checked our results against the a series of publicly available block lists, we have spammers DBL, the DNS family and Phishtank and we saw over the period, they didn't apply to many domains, there were at most 50 domains actively flagged at any given times which is relatively little. What we found interesting also was that the median time to flag was very short. We saw our, these domains appear on the DNS data and on average the day after they were appearing, block list so that's really good. What's not really good is that the median persistence of these domains was over a month. With a quarter going over 150 days. We tried to personally fix these by signalling ourself some domains to the .kids foundation which is the responsibility for the maintainers of the .kids gTLD. And we found that some abuse report button was not working for the whole time we were measuring the .kids gTLD. We signalled that and that was fixed but still we are trying to we are still in talks with the .kids foundation to have a system to signal domains because right now this data I showed you before that mention 180 domains was from last summer. Since then the number of domains has increased and we need a system to signal in mask which is not existent at the moment.
Finally the popularity is relatively low, only 44 had domains entered in the .kids Tranco top one million of these 23 were piracy or unauthorised streaming service, the rest was gambling and only five served active children suitable content.
Which means that again the domains that become popular are not the ones that we will want.
I think the highest position was around the 2,000 for piracy service.
So overall we conducted this measurement and what we saw, all the pieces of this puzzle bring us to.
We saw gTLD that does not, did not grow in an organic way. It's not actively maintained when it comes to the signal and the removal of abuse content. It doesn't... is completely inactive and doesn't abide by basic best security practices, in general .kids gTLD can be considered a failure and a representation of the fact that good policies and good idea without active application do not lead to anything concrete unfortunately.
But there is some signal of improvement. In the last measurement we did we saw Disney, for example, has registered a lot of domains so it's not everything is lost yet. But there is need to work on this.
This concludes my presentation. Thank you very much.
(APPLAUSE.)
BRIAN NISBET: Thank you very much. While obviously this community is more interested in numbers than names, obviously there's also a lot of crossover and a lot of people in the room who look at and work on these things which is why we felt the presentation was very suitable.
Questions. Comments. There is something from online anyway.
AUDIENCE SPEAKER: Hello. Great presentation, it shows us sometimes even the good premises don't have great results. Anyway, what do you think will be a solution to this? So apart from continuous monitoring and somehow maybe a risk‑ based approach, do you think that is lacking from the registry part on checking these or from the register, on checking better the accuracy of the register to force better policies themselves, I think here is a problem not enforcing your own policies.
MATTEO LIBERATO: Yes, absolutely in this case the vast majority of the violations will have been sold by just having somebody check the name of the domains, if I am registering Galaxybet .kids or even a porn website, it it should be the obvious that site shouldn't be there and yeah, on the other end, we also saw that there is an act of negligence on the part of the submission of obvious report, it was impossible for us to report until we signalled to the .kids foundation itself. It seems there is a bit of a lack of interest and action on every side of the problem.
AUDIENCE SPEAKER: I think we need a bit more housekeeping, we will see also in the next gTLD round on in 2026, I think we need to be careful about which domains will grow and how they are used by the end user and also by the registrant, thank you. Keep up the good work.
BRIAN NISBET: If one was to be very cynical, one might wonder in this age of undying rampant capitalism until it dies, that that wish to have money and make money is going to overwhelming a lot of things especially if the foundations or otherwise are under staffed and under funded themselves. But, yeah.
AUDIENCE SPEAKER: Just one question online from Asbjorn, what was the kids foundation's response to your reports? Did most of your signal domains get suspended or deleted?
MATTEO LIBERATO: It's still an ongoing process, we signalled the fact that this report button didn't work roughly two weeks ago, since then they responded to us quite quickly actually and they said the report button was reinstated on part of the website, there were a couple of ways to get there and only one works. But the problem is that the abusable session is a page in which you put the domain name, a screenshot of what you are reporting against and an explanation for an individual domain. Even now between the policy violations around the virus total and Cloudflare signal and everything, around 300 domains we would like to signal, it's not feasible manually, we sent them an email asking for a system to mass signal domains or at least to provide a list that they will then follow up on and the answer to us today, that they are working on it so it's very much ongoing.
RUDIGER VOLK: Someone was saying the word rampant capitalism. One stupid question for me is do we have an idea of how much, at what level, comparable, is the pricing for these domains? And does that pricing actually create enough revenue for controlling? By the way, of course, a high price would also discourage abuse.
MATTEO LIBERATO: Yes. On our side we are more into the measurement part of this, so the economic part we looked at but we didn't explore in enormous depth, we know that the prices is in line with other gTLD of this kind that were created through the community programme and we know throughout the first year that they had a lower price due to the fact that it was new and probably as a way to push people to register something.
BRIAN NISBET: I mean also there's, you know, obviously there are questions about the general creation of lots more TLDs and who is making money out of that. Indeed.
Any other questions or comments?
In which case thank you for fighting the good fight on this and thank you for the excellent presentation.
(APPLAUSE.).
OK, we should have Usama online, he was online earlier, OK. We can hear you and you should be able to, I think your slides.
MUHAMMAD USAMA SARDAR: I see the control. Can I start.
Thanks. I am Usama from the global alliance for Geonomics and Health. And I am the Chair of... which I describe and there we have an overall idea of how to secure the heat data online and that's what my talk is, I want to thank all the people mentioned here who have contributed to this.
BRIAN NISBET: Sorry to interrupt you, we don't ‑‑ I see the slides now, cool, sorry, they have just come up in the room. So cool.
MUHAMMAD USAMA SARDAR: OK, so, yeah. This is about attestation being very harmful, what we found out and we want to ask the operators why is it required and that's the whole idea of this talk.
So there are two main goals for this specific talk, and namely that I will be trying to seek the opportunities for collaboration with the RIPE security working group and the second one being that what we have found out is 40 plus million Germans' health data is potentially at risk, that is what we have figured out and that is what I will give an idea about.
And the goal of course is that how we can actually collaborate to fix that problem and find collaborative solutions on this one.
So, GA4GH example is this: The domain that I like the work what it's physically trying to do is you have some patient of some hospital and there is some personally identical information by which you can identify individual and then together with its health records and all the data. And then there is some computation to be done on the cloud side you see on the right of the slide and there is a trusted hardware, trusted execution environment which is hardware rooted and there is some end processing, everything nowadays is just AI based and there will be some inference, let's say after processing that, it will find out whether the patient has a specific disease or not and how to improve their models and so on.
There is typically which is very common the network adversarity, we know about that, there's a TLS protocol or any of the protocols you can use but there's something new here to say that the end point adversary. You do not need to trust the cloud provider, it should be possible without trusting the provider to provide the data within the hardware routed... and the computation will be done within that par within that partt, it will depict that within that hardware... encrypted before it sends back back to the patient or to the hospital or whatever that user or operator is. That's the whole idea, instead of just having the DNS protocol or any network protocol there is in addition a process of attestation going on and the combination basically protocol two protocols, more attestation and TLS is recorded as attested TLS, that's on the slide, attested... and what GA 4GH, there's a provider called SS systems and their solution actually just very recently recently a couple of months ago won the second place in the best of the technology awards of. ..and what we found out basically a couple of CVEs applied to this solution which are really attacks number one ‑‑ relay attacks, which means that basically the cloud provider, that expected host of which the patient or the hospital was expecting is relayed over to someone else and the evidence is coming from somewhere else and the collection is at some other place.
So there is two binding two taskses connection which is shown here like the confidential data going towards the cloud and the inference results coming back and the second key problem is that there is a diversion attacks and I have a CVE number as well, there's no binding to the hardware actually, all of those negligents are sold by the name hardware hooded or hardware based but we figured out there's no collection going down to the hardware, it's all done within that software, the TPN actually the physical TPN trusted module never gets to signed anything and everything is done within that virtual environment, it's the virtual TPN which is doing that, it's just software based, there's nothing hardware based in in there.
Then this is the comparison very quickly to give you... I just showed you two of those CVEs there are a lot of those you see on this slide, like where do we actually stand, CVEs are from zero to ten, to do just according to the NIST criteria, based on that standard, once that already existed are shown here in the table up to the 5.9 in the hold of confidential computing. And the ones in the red, and start from 7.5, the ones we have found, starting from 7.5, 9.1 most of them and going all the way up to 9.6 and what I am not showing here on the table which is still ongoing is even 10.0 as well.
So, the key point or the key take away from that is that the severity of the problems that I am mentioning here is quite high and they are easily exploitable.
The cost of this, I will talk about specifically two of those which are shown here in red 33697 which is going back to the one I had already in the beginning, there is no connection to the, there's no binding to the connection, and that leads to, implies that that would be possible so the data goes to some other machine which is the network did not expect. The one at the bottom is the 100835 which is the hardware binding is missing, not the connection binding, there's a difference between that and that was trying to highlight it in the very first line, connection meaning the DLS connection and hardware meaning that signatures. So there is no machine identity which one can reliably catch that this data is actually being processed in this specific machine.
So that's currently not possible.
Or at least what we can claim is that at least the systems solution which is deployed is not doing that so that was the issue.
And basically what it implies is that the physical host is... and why that is a problem, that's a problem because now it can be anywhere in the world, number one, so many of the countries are not in good relations let's call it this way and it's not suitable for them to have their data or health data or hospital or medical data being sent to some other countries and there are also very strict regulations that geopolitics has to follow and which advises that the data within a certainly locality, that could be defined by a country or even a smaller ‑‑ a big part of that.
What it mean, why it's problem at I can, the domain basically, the argument there from the community is for instance that it's not a problem if there is a lab selected, it's still secure, it's not correct because it's possible via physical attacks if it's in the hands of the adversaries... so that's the core problem.
So here I will just give a very quick over, so we have all these solutions mentioned on the slide, the ones written in black are basically the ones which have been either archived or migrated or withdrawn so two of them the internet drafts are as you see are one of them is withdrawn, the other one is archived. But the ones shown in red is the system contrast, the solution I mentioned, the beginning is the one which is following this withdrawn draft for draft FOSS satity seat early attestation and there is a new draft which is no shared secrets within that binder, the binder from the attestation to that collection.
So this is very quick status of the published security advisories and the CVEs, we have 39 advisories and 14 published ones and the rest are being processed, as you will note from this slide most of them are in the higher range, that is from high to critical.
It's already in the news and quite a lot of them confidential computing trust mechanism is broken, the fix may not exist, the core of the trust mechanism is broken down and may be irreparable, so on, it's still rightly in use.
And the CVEs are coming, here's is a list of a quick list of a number of CVEs which are still under disclosure and they are to be published
What's the ask for this specific community? Do we need stronger regulations in order to regulate better these big algorithms or big protocol and bindings buying not only to the connection but also not hardware what secured your data remains secure and specifically talk about all the problems I mentioned are related to earlier attestation, there is a better solution which GA4GH Reseources has approved, completing the DNS protocol and using the exporters from the DNS protocol RFC 9261 in order to do the standard attestation for that and to our knowledge, it means there's no security of privacy property which early attestation can achieve which standard attestation cannot achieve and this is a point for discussion that why is the community actually using early attestation at all.
These are the links to the GA4GH Resources resources, there is a draft already which is‑‑ this was just supposed to be a starter for the discussions and there is a paper next and in issues, the other paper crisis the vulnerabilities and that's coming soon, I will I would like to thank very much my co‑authors and people who have been writing drafts and papers with me. As well as a number of contributors from the several companies and so on who have contributed to all of this work.
Thanks very much and I am open to to questions, comments or any feedback or any thoughts you might have.
BRIAN NISBET: Cool, thank you very much. So, questions. Comments.
AUDIENCE SPEAKER: Just one comment. Just to bring the attention of the behalf about IETF processes, all the documents where there is IETF in the URL, they are draft, not IETF, they are not adopted, they have no consensus yet.
MUHAMMAD USAMA SARDAR: Sure, thanks.
BRIAN NISBET: OK. Anything else? Thank you for bringing our awareness to it, it's obviously something to discuss and work on through the IETF. But yes, if this is of interest, people in the working group, then the IETF is the place to go and talk about it.
MUHAMMAD USAMA SARDAR: We are already in the discussion with the IETF, the draft I mentioned here, so as Eric was mentioning, it's individual draft, so it's already in discussion with the IETF. The idea was that the regulators or the operators can give us some insight on why is the interest in early attestations, all the solutions I mentioned here, none of them were actually using the ‑‑ for instance on this slide, the question for discussion is when a standard solution exists, RFC 9261 which is indeed an RFC and not an individual draft, you can USE the exporters from DNS in order to do that finding, in a standard way. So why are the operators not using that one specifically and why are they insisting on early attestation given the number of the variabilities that we have reported and brought on the public in general.
So yeah, that would be our hope that we would hopefully listen on the list or anyone is become to contact me by email or join our list that I will also share on the RIPE working group list, security working group list.
BRIAN NISBET: OK, you if you want to send to the mailing list and maybe so some discussion there, sure. Thank you very much.
(APPLAUSE.)
OK. So Alistair is going to talk to us about running a CNA in the time of AI because we almost got through the entire session without talking very much about LMs yet here we are.
ALISRAIR WOODMAN: So for I think many of you may know me here at the RIPE because of my work with the FRR community, I also work in another area of OpenSource stuff, so I happen to be, if that works, now we have got screen problems.
So I also work in an another area of OpenSource project and I am on the board of the airline ecosystem foundation, that covers languages like Erland, Elixir, Glean, the Starfish on the other side. Can I have a brief show of hands of anybody who uses this technology in anger? There's at least one gleamer here I have run into at the event.
OK, fine, we are a small middle side language community, nowhere near the size of Python but we have a very fine VM and we have to worry about our code and we probably, we have on the order of 20,000 packages out in the internet that we tend to want to care about. Developer numbers of are of course always difficult but if you count sort of the top three languages that people work and play around it, we probably got about 100,000 people who use the language more than just occasionally.
The corporate users which have been slightly cut off here, we have got at least 5,000 that I think we know about, including some of you who are sitting in the room at the moment.
So lying anything, the hardest part about stuff is naming, fortunately we ended up naming our security working group stuff, we started about two years ago and this was originally kicked off because of the European cyber resiliency act, it was relatively obvious that we needed to pay attention to this from a community perspective. And thankfully we did do that because AI has actually caught up and overtaken any requirements that anybody had about complying with the law at the moment, you better comply with this because otherwise life can get very interesting and complicated.
And just to give you a background, the level of this talk will be mostly the community level, we are dealing with lots of packages, a huge amounts of people so this is mostly a talk about humans and how to deal with process in the time of AI and not specifically getting down to any particular CVE as such but I do think for all of you in the room, if you do care about security, it's all about how things work in teams and one could argue if you have read the interesting conversation about the PHP stuff and whether ChainGuard should or should not have put out their stuff early or not, you can see that people get very angry, frustrated about behaviour in this types of things and it's very important that you manage your community and deal with those types of things so that we don't end up with problems in amongst the community.
We set up a CNA team, these are their five principals on the team. For those of you who are aware of it, the virtual machine is maintained by Ericsson. So their principal, there's probably about 15 folks in Ericsson who are actively maintaining the core of this technology and the other four people on this list here are actually just community members who actively were working in our security working groups and as we looked around to try and get people to line up, we tapped these folks on the shoulder to step forward. And as you will see a little bit later, Jonathan and Peter are doing most of the work as far as the dealing with our CVEs as well as doing the AI research on them.
So the state of the world, I will probably go through these relatively quickly at the moment. You have seen something like this already, we are living in if a time of hyper exponential growth and for anybody who studies exponential growth, this is an interesting space to be in, so if things are going faster than exponential, you have a complete face change in the way things are going to go work.
This is not going to be the same life in a couple of years that we have been living two years ago.
We see this activity as well, we have now got access to Mythos, we didn't have it up until within the last 30 days we are a slightly smaller project on the alpha and omega open SSF project list, but we have been able to find and deal with most of the AI exploits that we found ourselves in our own code base, not using myth OS. So if you have appropriate folks on your teams that know how to want get this technology, you can be very successful without the best cutting edge technology.
This is worth going and looking at because we are trying to keep track of who is behaving themselves and who isn't, but and of course this I think is just the canary in the coal mine when the guy tried to ask his AI to get himself posted on there and you have seen this, the AI then went and removed somebody else off the wait list by hacking into their account. So I think the person did this on purpose, to see what bad level of behaviour an AI would get up to. But if you are highly motivated and somewhat more malicious, this technology can be used for all sorts of interesting exploits at the moment.
And I am at the moment quite surprised we haven't seen quite the number of activity that I would expect to see and I do think they will be coming. I don't think that we have gotten, we haven't reached peak bad behaviour at the moment.
Some of the responses of corporate America and other large companies as an effect of the announcement of Glass Wing and what has happened ‑‑ last week and what happened is they are basically trying to pull up the draw bridge and deal with the bugs in their own code base and down the torpedoes, this is a reasonable choice if you are a large organisation especially, if you are a bank entrusted with other people's money, it would be what I would hope that my bank was doing.
The interesting question is how are then corporations that are doing this going to work with our OpenSource upstreams over time and this is still very unclear topic amongst us in the community.
So what are we doing and how are we protecting our ecosystem with AI. So as I mentioned before, Peter and Jonathan I think we got exceptionally lucky in our community in the fact that we are in th‑ Goldilocks zone, the language doesn't really attract the folks who want to do drive‑by AI exploits, we are not big enough to be sexy, we wouldn't necessarily get on the front page of any of the hacking news sites and we got very quickly involved in the situation where Peter, who happens to be show the proclivities of being able to wrestle with AI and actually prompt it ‑‑ for instance, one of the first things he did was tell Opus pretend you are Mythos, go find stuff, right, and that actually works quite well. If you haven't tried that trick, go play around with those types of things but we had Peter and Jonathan working backwards and forwards and because they managed the queue, Jonathan can provide push back to Peter about don't go and overload by queue depth and Peter can find stuff as creatively as he can with all the latest models and we go around that circle and cycle very quickly.
I don't think we have ‑‑ I think from a language community perspective from everything else I'm aware of, we have the least turbulence in any of the language communities at the moment.
And given and I was saying this even before last week but I wouldn't want to be in the shoes of PHP and some of those language communities where things are much more diverse.
Anyway, we get to work through this process. Again, the hardest part about this is getting the maintainers to actually halt what they are doing and actually deal with stuff.
So we have a good process from the CVE side but getting the attention of the maintainers to go do stuff and we're actually even experimenting with the idea of telling a particular project OK, we are going to go focus on you now, you need to block out the time so that you can go spend the time, halt whatever you are doing and we'll provide you with as many CVEs as we can find in the cycle so we don't keep continuously interrupting them and we have a sort of batching process in their area. But each project needs to be dealt with separately. There are people involved and it's always an interesting situation.
This debate comes up a lot. And so we have certainly moved from treating low level vulnerabilities and CVEs to things that we are fixing because there's a lot of stuff to keep moving on, finding is easy, fixing and verifying is a lot more expensive, we are using tooling for this, it's still not cheap.
As I mentioned before, maintainers are starting to burn out. And they need some love and T.L. C.
This is what we found up to date, I wrote about this at the twinge, we have gone from literally having about ten CVEs last year to probably we will end up this year with over 500. So that's a 50 times growth and this is just because they were always there in the first place, we couldn't find them. So you have all got this problem in your own communities.
Because we did this and because we got organised, we are actually pretty high up the ranking at stuff in, for example who actually pay attention to score cards in this particular area and I am personally very proud of team and the work they have put in forgetting us to this particular point, this isn't our reason for doing it but because of the way he have we have actually executed and been organised, we are doing a pretty good job with very low level of resources.
Probably need to speed up here. So again you can go look at this, but it's a usual process of how you report a CVE issue.
Go use an AI to help you, if you are using your hex package manager stuff, connect it into your CICD, that will help and protect your secrets.
And I think I am probably out of time.
BRIAN NISBET: You have another minute maybe but...
OK the last thing, who pays for this work, at the moment I go around and beg very hard for sponsorship, I need to give a big shout out to alpha and omega what host been funding a lot of this stuff and they have been doing a very good job funding package managers generally in this particular space. As you can see and as I mentioned before, there are people using your technology not on the sponsorship list and quite frankly you should be so come and talk to me afterwards if you think your company is using the technology.
And with that I will stop and give time for Q&A.
BRIAN NISBET: Cool, thank you very much.
(APPLAUSE.)
Comments. Questions. Existential panics.
I mean, I think this is something that ‑‑ you are not unique in seeing this, but it certainly lays out a good framework for other people. There's something online? No? OK, I don't know where you are. Yes.
MUHAMMAD USAMA SARDAR: I have a question. Yes. So I was working just about my talk that I just presented, that you are using formal letters in your CCD finding process number one and you said that the finding is cheap. But in our analysis as finders ourselves, we found ourselves in different shoes which is to say we have a different position like the maintainers, I agree with you on the maintainers point that maintainers are really hard to convince and move forward and to apply these. And so on, I have an impression that most of the maintainers actually were not... by the for matter... we have to show them look, this is how this works and so on and I was wondering your experience on both of these things as well as the effort that the finders themselves do and why you believe the effort for the finder is cheap. Thanks.
SPEAKER: I think it's an interesting thing if you are with inside a language community or you are inside of a language yourself, right, you are mostly focused on making sure that, you know where the foot guns are and we do know now where most of the foot guns are in our language area. So we are actually being able to go and look and reason about libraries from the inside without having to test them like in an network environment from the outside.
So I think there's a very different aspect of whether you are testing a system for vulnerabilities in which case you end up having to do things like fuzz the outside of the system versus when you are looking at the inside of the code and you can ask an AI to reason about it. As far as the formal method stuff is concerned, we are all over getting formal method, we are a functional programming language, we have lent, joke, into the lean stuff, we are building proofs for those types of things. And I think this is going to be the way to go if you are so, if any of you are nerdy folks who want to do lean proofs, come talk to me as well because we are interested in that area.
BRIAN NISBET: OK. There's no nerds in this building! Nonsense! OK, anything else? In which case, thank you very much Alistair.
(APPLAUSE.)
BRIAN NISBET: So we'll move on. So OK, so those of you who are regular security working group attendees would know we would normally at least ask a what's been talked about on the list and policies piece and so this is the what we have been talking about on the list the policy.
So we have a policy proposal 2602 which Denis is has proposed. And unfortunately Denis couldn't be here, but he has sent us a video. Now importantly you will have seen that he is talking about version 2 of the proposal, the discussion phase on version 1 runs until the 11th November and we won't suddenly be providing a version 2 prior to that, albeit I think the proposer has flagged his intentions there, the working group chairs and the policy development officer from the NCC need to talk to him about version 2 and what that looks like. So the video you are about to see is talking more about that but we are still interested in discussion and input to the thought process on that as Denis continues to work on version 2 and I will let him use his own words.
One thing I want to say about policy discussions for those of you who aren't Address Policy wonks and very used to this, the very this makes a difference, you have to be on the mailing list, we are not at the point of talking about version 2 yet, we don't have version 2 and indeed the discussion phase for version one is still ongoing. Equally I would like to make it clear the security working group cannot force the NCC to do a particular technical thing or address something in a particular way.
Working groups can make policies that say you should do this and then we let the NCC figure out how to do that and that's part of the impact analysis which is part of the PDP and sometimes the members care about how much money it might cost.
All the time.
So yeah I wanted to give that context before we play the video and we'll have sometime for further input and discussion, but I would say and I will remind people at the end that it has to be on the mailing list to count. So with all of that in mind, can we play the video please.
SPEAKER: Hi, I am Denis Walker, retired RIPE database senior analyst engineer. Let me first apologise for not being with you live today. Unfortunately medical appointment had priority nothing serious, but it needs attention. So what I am trying to do and why. Let's start with the why. Cyber crime is expanding rapidly and hitting many elements of daily life and AI hasn't kicked in properly yet. Food, energy and water distribution, hospitals, transport, education, banks, they have all been targeted. The public is start to go notice. Cyber crime is no longer people in hoodies hacking parent companies no one has ever heard of, stealing personal data that never seems to affect anyone you know.
When the public notice, politicians take note. It means votes are at risk. They will look carefully who has the power to do anything about this. I think this community is going to be in their sights. Taking action now voluntarily when you have time to carefully think about it is better to reacting to any emergency legislation that might come down the line a lit later and we have had 20 years to think about this.
Now we need to act. And it needs to be effective. You no longer have the luxury of sitting back and saying that it's not our problem, it absolutely is your problem. And it's not going to go away.
Many of you know me as a RIPE database expert. I am not an expert in routing and security issues which is what we need to be looking at for this. I am learning fast and there are many systems out there tracking abuse and identifying networks of interest. Some act responsibly and take effective action when they are notified, some do not. We need a policy with real teeth to force accountability and action on to the LIRs when it's necessary.
My first thoughts were to use an RPKI freeze. If we only had hosted services, that may well have worked, but once I discovered delegated services, that idea hit a break wall. So totally dropped the idea of using PQC in any way.
As I said, I am not an expert in writing but I have no problem admitting when I'm wrong. If you hit a brick wall, backtrack, take another path.
Doing a bit more research, I believe that tier one transit providers still use IRR objects to build a daily writing policy, some form of write injection with AS zero origin, then I realised a valid ROA would override that injected object, so that also hit a brick wall. Try again.
Now I think I find the right approach to combine ROA injection with AS zero as well as route injection with an origin AS zero the full details of what I'm thinking on this will be published shortly. It's designed to safely isolate verified malicious networks while aiming to protect legitimate operators.
Unless the LIR intentionally embeds them within a customer network block. Let's address the elephant in the room straightaway. In our region, when a bullet proof horse that persistently shields severe threat actors, the internet community can point fingers and can scream, place them on what lists, it seems you can't actually touch them; they don't seem to be able to do anything about them. Transit providers can block traffic locally but they can't strip a hoster's cryptographic organisational wear. The RIPE NCC holds a unique localised monopoly on the route to trust anchor in our region, because the RIPE NCC signs the parents certificate and maintains the authoritative routing registry, they bear a fundamental responsibility for the integrity of that data.
If a rogue actor uses RIPE NCC that's own cryptographic signatures to weaponise address space and ignore this community, the registry is the only body that can administratively rectify those records when instructed to do so.
Version 2.0 provides a mechanism to do this safely.
To ensure absolute enforcement while avoiding collateral damage, version 2.0 operates simultaneously across three distinct technical planes, first we had the cryptographic plate, the RIPE NCC can inject highly specific AS zero ROAs for the exact offending prefix while removing any existing ROAs. This forces RPKI validating Tier 1 routers to drop the criminal announcements globally within, I believe, 30 minutes.
Second we have the traditional registered plane. The RIPE NCC uses internal administrative override capability to partition and lock down an exact match object locking it strictly under official strict RIPE NCC maintainer keys. Also create or modify exactly right objects, strip it away, the origins and map them to AS zero.
This locks the LIR out, preventing them from subdividing the block or routing and the filter.
Third we have the identity plane where the NCC can delete the existing reverse DNS shall the main objects for that range, recreating them with name service records, pointing strictly to authoritative registry and black hole servers; this ensures that criminals cannot exploit the naming identity of these IPs to authenticate malicious spam or phishing campaigns occurring elsewhere on the web.
There are some people who are now thinking this is supposed to be about enforcing accountability on LIRs, and yet they may think I am asking the RIPE NCC to take down networks without any authority.
That's not the case. I am asking the RIPE NCC to enforce integrity over its own registry data.
That is a purely administrative act and it's well within the RIPE NCC's authority.
Over the last 20 plus years the RIPE NCC has changed user data for a whole host of reasons. The acceptable use policy for the RIPE database and the term of conditions include many articles that give the RIPE NCC the right to change data. We also they also have the right to change the terms and conditions, they seem to be well covered with the authority needed to make these changes to the user's data. It's often said we must never turn the RIPE NCC into the internet police, nor into a judge, jury or executioner position.
I entirely agree.
Under this proposal, RIPE NCC staff perform zero investigations, they make zero technical evaluations, and zero subjective judgments. The entire system is driven by explicit deterministic key words and by an automated ticketing script.
In fact, the whole process can be automated.
The RIPE NCC does not make any decisions, it takes actions when instructed to do so.
The new policy proposal includes appeals, processes and protects identities of IoT holders to avoid any retaliation, which were some points that were brought up in Michael Duffy's analysis.
Now as I said earlier I am not a routing expert, I have been pushing the boundaries of my knowledge constantly the last few months. But I will never match the experience that many of you have of sitting right now in this room.
The whole philosophy of the bottom up community driven policy development process in a self regulated industry with a high‑risk of conflict of interest claims, it's about collaboration, co‑operation, meeting of minds. Working together to develop an effective policy.
I hope to have a new draft, an outline of the logical implementation published soon. I really hope some of these communities willing to work with me to make sure that the design of any routing implementation ideas will actually work.
I have been struggling my way through this for weeks. Some of you may just know how to do what I'm proposing. So to conclude, policy 2.0 does not grant the RIPE NCC the authority to police the web. It grants the community the automated tools to ensure the RIPE NCC's own database and cryptographic signatures are not exploited to hardware our criminal networks.
It is precise, it aims to protect innocent neighbours and it leaves the decision‑making entirely in the hands of objective routing data and authenticated IoT handlers. I welcome your technical feedback in the following discussion and in the mailing list. I look forward to refining the text based on the working group's review later this week.
So that's a rough outline. Please discuss.
And thank you for listening.
(APPLAUSE.)
BRIAN NISBET: So we all remember all the caveats I gave before the video, just. Just to say out loud. I am obviously not Denis and there is no no one on this side of the podium to discuss this with but certainly if there is feedback and again I think I would just echo what Denis said at the end there which is if people feel this is a problem and making no assumption either way, that needs to be solved and worked on in the policy, then collaboration and co‑ authors would be useful for them. Leo please.
LEO VEGODA: I am just speaking for myself, not on behalf of anyone else. I would like to thank Denis for putting so much effort in this proposal. I only read version 1 and it's clear the amount effort that's gone in. I feel it's a curate's egg, which is a very English way of saying that while parts of it are good, the bad parts make it inedible. And I am just going to say ‑‑ refer to one aspect. What Denis is asking fundamentally changes the relationship between the RIPE NCC and the RIPE NCC's members. There has recently been a discussion over the last couple of meetings about the new neutrality of the RIPE NCC, to my understanding the neutrality has essentially been renewed by the most recent strategy document after consultation, this would change that and that's fundamentally a risk. And I think that there is a lack of risk analysis in what what I read in version 1. I only want to talk about that aspect of the risk but there is more and so I would hope when Denis brings us version 2, it really looks at risk much more carefully.
BRIAN NISBET: OK, that's a very important point for Denis as well in considering version 2. Please.
AUDIENCE SPEAKER: Hi. I am a student from Bulgaria, I want to share an experience regarding topics and raise a few of my concerns. This summer AON Bulgaria booked my domain from their DNS and ‑‑ as a phishing and it was based on automatic heuristic and their sink hole was broken and I tried to reach their abuse C contacts but because they are not exposing security TXT, I tried...and Abuse A and after that I reached for the Abuse‑C from RIPE DB and mye mails just bounced. So after a month without a reply, I contacted the RIPE NCC and they told me they are only responsible for email that exists and not responding so the concerns I have and the things I want to share is that I support using third parties as a way to collect real data on malicious operators but I think the framework existed because we admit that Abuse‑C is0 ‑‑ just doesn't work. And second, the block list. And the list we are using to collect the data based on which we are going to future. Many operators were replace context with ticket systems and call centres which I think is a problem. Because this is a filter this is meant to, don't pass the non‑technical peoples but a problem for me. So I think we need to define what working abuse contact is here, thanks.
BRIAN NISBET: OK, thank you.
I mean this is ‑‑ and thank you for coming along and it's great to see new people and more students at RIPE meetings. This is a conversation that's been going on for sometime, I think you have neatly encapsulated both sides of some of the problem there in relation to both automatic heuristics. And indeed people not answering their Abuse‑C. So it's a very ‑‑ I think it's a very good story from a number of points of view and I think it does again indicate that progress we need to make, what that progress looks like and in what way is of course the question. Thank you.
AUDIENCE SPEAKER: I agree that the Abuse‑C sometimes is not the best because probably doesn't even refer sometimes to the end user or the technical one which deals with the results, but anyway I seen this proposal a lot of good points about we need to have this discussion, there is a lot of cyber crime at this moment, we don't want the RIPE NCC to be the network police but we really need to understand if there is a way collectively as a community to collectively to discuss if there is a real solution to the issue, I don't know if outsourcing to third parties is the right solution because it depends on the third party you use. It can be really weaponised to close some activity. So also not only the problem of collateral damage, it's also the problem of who takes the power to be the one deciding. So I think there should be a thing that us as a community has to be decided. So in a way that the third party is where there is also behaviourally checked by the community itself. So I don't even know if the technical solution is the right one. I saw about that RPKI, but I am not really a technical expert on the RPKI. So in a way I don't know which will be the right solution to avoid as much collateral damage as possible and make sure that the owner of the one that is using the internet resource is responsible enough to correct any abuse issue.
So I think that this proposal has some issues and I also see that it could be also many technical costs on how it has to be done and also resource costs. I don't know if the RIPE NCC is willing to take it. I am also waiting to understand which will be the analysis on that. But I think, and I state it again, this is a discussion we want to have. Also as a law enforcement. Because if there is something that us, that is possible to be done, it has to be done and we have to discuss it and I know that the RIPE NCC wants to remain neutral, everybody wants to remain neutral. But in case it doesn't want to address these as a police internet agency, we can find the right body that has to deal with this. And so to take also RIPE NCC away from any issue because it has to remain neutral, that's from my side. I welcome the proposal, I don't know if it's the right way to address it but I want to be in the discussion, thank you.
BRIAN NISBET: Cool, thank you.
AUDIENCE SPEAKER: Hi, I have a few points. First, this proposal does try to make the RIPE NCC part of some kind of internet police and I think saying that it doesn't is playing the kind of semantics games that should have no place in this community.
That's first and I think an important point.
Secondly, I agree with what Leo said about risks, I won't repeat all that.
My final point, we don't need to build some kind of internet police, we already have a police, I think previous commenter, as part of that. This police that we have, it polices the real world, the virtual world, all of it and it is based on its own and it uses constructs like legal systems, laws, all of these things that have been developed over centuries and I don't think we should even try to replicate that work in this room.
BRIAN NISBET: OK, thank you.
(APPLAUSE.)
Is there someone online with a question. Let's ‑‑ people online do not get left at the back of the queue because other people are in the room.
SPEAKER: One question from the Q&A. Max asks: The proposal excludes the nets for subscribers, this means this type of user are free to do abusive things while for data centres it's prohibited, why is this discrimination for DCs?
BRIAN NISBET: Those poor data centres, they are discriminated against all the time.
Yes, ah, yes. I mean, thank you for the feedback, max.
Michele, if you want to request the mic.
SPEAKER: Michele Neylon. I have huge issues with the proposal as currently drafted, whether to be the first version or second verse. It seems to be kind of et let's run a marathon before we have even jogged up a small hill, it seems to be going from zero to a hundred with very little in between. So the, like right now we have the obligation for resource holders to publish an Abuse‑C, which took quite a bit of time to agree but it's there and that seems to be working.
What we need right now I think is a simpler proposal to oblige resource holders who have an Abuse‑C to be responsible, I think that, in essence, is a large source of frustration. The proposal as written is creating a massive overhead both for RIPE NCC and for the working group as well. I mean, I don't see how the working group is going to adjudicate which block lists are good, bad, indifferent and how to manage that on an ongoing basis. The last time I checked there were volunteers and not enough us had the expertise to be doing that.
The automated decision‑making is hugely problematic from all sorts of perspectives, legally speaking I think that's incredibly dodgy. Excluding broadband users strikes me as well, rather weird. And so that's saying that somebody could, with a fixed IP, because they are on fiber broadband they can do whatever the hell they want. That doesn't make any sense. I think this proposal as currently drafted should be rejected and a much simpler proposal around getting resource holders to be responsive to their Abuse‑C would probably be supported more broadly. Thank you.
BRIAN NISBET: I am waiting for Jordi to burst through the door with the proposal he had a while ago. Is he in fact online? We'll let Alex go next. Thank you for the feedback. One, I think thing I would say and it's not me trying to say ‑‑ I am not the proposer of this proposal ‑‑ I think the residential piece was not to say you could do whatever you wanted on a fiber broadband, it was we wouldn't knock entirely countries users off‑line if a bunch of them had dodgy boxes that were doing malware, etc, so it's not about saying someone can do whatever they want shall it's about controlling the area of effect, the blast radius of any actions that were taken. But again, not the proposer.
SPEAKER: Alex. Part of my work is regulatory, talking to the EU, IPO, the euro peep intellectual property office where rights are very strong working with Europol talking to the Commission and one thing that always comes back is that the data within the RIPE database isn't suitable for finding the real perpetrator, I do understand what is the reason for basically proposing this. I think we as a community we need to pick up, we need to do something, I don't know what is the right thing to do. If we decide it's not our problem, then the Commission will come with legislation and basically force us to do stuff we definitely do not want. So we cannot sit back, relax and let the storm, you know, blow over. We have to pick up and do something. What is the something, I don't know. But we have to do something.
BRIAN NISBET: And I would remind folks as well the database working group and RIPE NCC Services Working Groups have their sessions later this week.
Please.
AUDIENCE SPEAKER: Thanks Brian, there's one more in the Q&A, Jordi... says: It is ridiculous for a serious security working group, you still believe that asking for an Abuse‑C email that may not work and it not enforced to work, we need to change that. Checking a responding Abuse‑C in APNIC and LACNIC and soon in AfriNIC demonstrates this is needed as the abuse case from those regions are lower than from from RIPE region ensuring the Abuse‑C is read doesn't change the RIPE NCC neutrality, I am happy to bring that proposal back if needed.
BRIAN NISBET: OK, Jordi is welcome to bring that back. I mean, I say, I know it sounds like I am being flippant and I am not ‑‑ everybody is welcome to bring proposals. Please contact the working group chairs, we will help you with this and even put people in contact with other people to work together on this and indeed other working groups to work on this. So it's absolutely not me being flippant, it's about reiterating the fact it's a community activity and somebody's name has to go on the proposal and from my and the other working group chairs who aren't here and can't agree, it's something we want to see in this working group or a different working group,s we are not precious but it's something we believe needs worked on and are very happy to work with people on that.
Please.
AUDIENCE SPEAKER: Well, responding to.
BRIAN NISBET: Who are you?
RUDIGER VOLK: Rudiger Volk still and still retired. Responding to the remarks that Ed just read, I would come back to kind of my pet peeve from all the ‑‑ OK, you can do only certain things with testing and the interesting thing is what exactly is needed to check that an Abuse‑C is functioning. What kind of dealing with what kind of requests in which manner will be deemed acceptable or not acceptable? It kind of ‑‑ that is actually a rat hole and kind of beyond checking that well, OK, an XM points to an empty SMTP receiver is essentially a thing that can be done, everything of the handling is kind of things where you would need to, well, OK, essentially consider using a court and legal discussions in the end. Kind of for simple things, yes, well, OK, yeah. But in many cases someone who sends a message to an Abuse‑C may say, OK, I am a simple minded user and I am not happy with the competent response that I got.
BRIAN NISBET: Yes. OK. Thank you. And I think that brings that discussion to a seemingly natural end, as there's nobody else in the queue either online or in the room.
Again the discussion phase for this version of the proposal runs until the 11th November but the co‑chairs will talk to Denis, get more feedback on the list and using my immense psychic powers unless something changes, I can foresee the future which is we will get to the end of this discussion phase, there is no consensus on this and we will look at version 2 and a new discussion phase at that point in time.
With Angela's immense help in the PDA.
OK. So could we just get the last slide up there please. Thank you very much. Is there any other business that someone is desperate to talk about?
No. Cool. So we are open to agenda items RIPE for RIPE 94 from now. We will send out reminders to the mailing list. If you have feedback, please do so via Pretalx or grab me in the corridor. All is good.
Thank you very much for your time, all the speakers, all of the support people who do things and we will hopefully see you all in Vilnius. Thank you all very much.
(APPLAUSE.)
End of session.