Session Date/Time: 02 Oct 2026 13:00
[00:00:04] Benno Overeinder: Yeah. Good question. So I prefer to have the q and a at the very end and the discussions. Maybe really short clarifying questions are fine just for understanding the presentation, but all the discussion is at the end of the of the session. And that will be kicked off by a statement by Wes, and then we can have a a a discussion on all the topics we... That have been presented or that are relevant. With that, it's, for me, 03:00, so we can start. Welcome. So I'll kick off. This is an IETF side meeting. So, also, ITF rules apply. So I will go through the note well and all the steps, and then we go to the first presentations. Right. Let's do this first. Good. Welcome. This is a side meeting of DNSOP. Chair is Benno and Andre, secretary Shumon and Peter, our technical adviser, Jim, and our responsible AD, Matt. He's also here in the room. Minutes, I already filled in Paul's Paul's name, but we will... It will work out. Good. This is an IETF meeting, so the note will applies. We all assume that you're aware of the note well and understands what it says. Please stay with the the note well and read it if you haven't read it. Good. The agenda for today, we have an hour. We have three presentations of ten minutes. Am I correct here? Four. Do I miss one? Oh, we have four. Sorry. I'm I'm miscounting. Four presentations and twenty minute open discussion. Right. So the topic here mostly is I ask everyone to think about a presentation, not presenting a draft, but what has been done and what still need to be done, what are the operational challenges for going forward with post quantum, Dean and Zach. So these are the four presenters, Paul, Bas Westerbaan, Andrew, and Paul again. So... And we also asked Wes to kick off the discussion with a statement, and that will follow-up the discussion. Before we proceed, any questions? Yeah. So the the Well,
[00:03:05] Mukund Sivaraman: I can't hear you. One moment, Ben. Maybe something wrong with the mic settings.
[00:03:12] Benno Overeinder: Yep. Okay. Playback. So, Mukund, do you have a question? Or... One moment.
[00:03:26] Mukund Sivaraman: Okay. I can hear you now.
[00:03:28] Benno Overeinder: Yeah? Yeah.
[00:03:31] Mukund Sivaraman: How are you?
[00:03:32] Benno Overeinder: Fine. So... But we are... The the meeting started already. So can you
[00:03:36] Mukund Sivaraman: Oh, I'm sorry. I'm sorry. I'm sorry.
[00:03:39] Benno Overeinder: Yep. Excellent. Yeah. So one of the outcomes... Well, there's no... This is interim, but one of the things we would like to take away... One of the takeaways is which work can be directed to a working group, which work should... Well, maybe target to discuss in a booth or other working groups, which work is still too early and and and should be, well, still at the PQC side meeting or something for a research task force. Okay. But that's all for the end. If no further questions, I'd like to hand over. Well, I will share the slides, but I will ask Paul to present the slide. Do you want to control the slides?
[00:04:30] Paul Hoffman: No. Please control.
[00:04:32] Benno Overeinder: Yep. I'll control. Yep. Let's see. Yep. Stop slides. There we go. Hey. Share slides. There we go.
[00:04:46] Paul Hoffman: Yep. Good. Good morning. I will go quickly because of the ten minute limit, so we have more time at the end. I will emphasize that this is just a temporary view of where we're at. It's certainly not a complete view, and in fact, as you'll see on one of the later slides, it's already been overcome by events. Next slide. So one of the things when people are are saying, what should we do about this? There are many considerations. I've done a draft here. Wait. Wait. Go back. Go back. You're going... There we go. Thank you. This draft, as it says right at the front of the draft, is not meant to become an RFC. It's just useful, I hope, to the working group, and to PQC DNSSEC list for listing the considerations that people have said out loud. And again, there are others that people have not said out loud or whatever, but going through them quickly on how we're picking what we prefer for an algorithm. Is it standardized by either NIST or someone else? How how quickly can it be deployed? The sizes of the records for keys, for signatures, or for both? How much CPU usage does it take other than just the TCP's usage? So signing, validating might actually be a lot heavier than what we currently have. Changes that are needed to the DNS protocol, some of... Some algorithms require processing changes, others don't. Is this likely to be included in HSM? That is some of the HSM vendors don't really care about DNSSEC, but we might get the signatures for free, we might not. And also how assured are we of the cryptanalysis so far. Next slide. So I'm gonna go through the three algorithms that we have already seen a bit on the list and then I'll do an omnibus at the end and again I'm really sorry if I'm talking so quickly, but with just ten minutes. So recently we've seen MLDSA dash 44. This is the algorithm that is used in web and secure mail and such, so this is the one that most people in the IETF other than the DNSSEC community is talking about. It's got an I n a number now for DNSSEC which is 18 and there are some resolver and authoritative softwares that are already having it deployed. Some of them are pre release, some of them are release, but we are seeing that. I'm also separately, I didn't put a link here, keeping a list of these. That's also on the PQ DNS checklist. Next. So for each of the three, I'm going to have a slide like this that goes through the considerations from before for these. So MLDSA has been standardized by NIST in FIPS two zero four. It seems deployable, that is the early indications since even that was just like a month or month and a half ago that it's plenty easy deploy. The size of the records is what will give people most pause. Every signature is 2,400 bytes. So every signature is gonna require TCP fallback. For other CPU usage, it's moderately fast. It's not as fast as what we're seeing, but it's okay. It does not require any DNS protocol changes. It's already in commercial HSMs. Again, not due to us, but due to other folks. And there's been an intensive amount of research on it. The assuredness is considered extremely high nearly everywhere. Next slide. So FNDSA, which is also many people know as Falcon, has already been discussed in... On the mailing list and for PQ DNSSEC. It's considered very interesting to the DNSSEC community because individual signatures would not cause a TCP fallback. It's also got interest in the IoT world for the same reason, so lots of people are looking at it. Originally, FNDSA required floating point arithmetic for signing, that was sort of its its trademark, But that has now... That is now being changed to fixed point by NIST, so it's going to be slower for creating and and possibly more CPU intensive for creating signatures, but what that means is it's going to be much easier for folks to implement. So in this, the standardization had been stalled, but just recently, and when I say recently, I mean on Monday of this week, NIST said nope, we're moving forward. So when I prepared the slides, these slides last week, I had to change this slide. Just note that Falcon FNDSA is not as easy to do signing as most other algorithms, you have to be sort of careful. So there have been some articles warning about this. Next slide. So standardizing, it is likely, but not definite, but likely that it will be a NIST FIPS. Probably, it'll take at least a year to get that out, maybe two. Trying to guess how long this will take is always tricky. It is definitely deployable if it's it's standardized, you know, people have already been showing how to do signing and and validation. The size of the records is what makes it interesting. Signatures are 666 ish bytes. What this means is a response that has a single signature does not need to go to TCP fallback. However, responses with two or more signatures would push, you know, are that sort of twelve eighty that we like. It, again, is moderate CPU usage, doesn't require any DNS protocol changes, probably will be included in HSMs, and the assuredness is medium high. There are some people who are complaining about weaknesses and signatures and also some related protocols have had weaknesses enough to kill them, but people have been looking extensively at Falcon FN TSA and there hasn't been any weaknesses in it. Next slide, and I'm still doing okay on time. So this slide got... This slide is now old, as I said, this temporary got changed two days ago, MTL mode, VeriSign has now switched from emphasizing SLDSA, SLHDSA to it could actually cover FN, well it could cover FN, but it could also cover MLDSA. So let's skip the first bullet, although basically what the first bullet says is, yeah, this is already covered by NIST. So many of the DNS seq signatures would be small, but signatures have two modes, condensed and full. Condensed means it'll certainly fit in a UDP packet, full means it would not. So if you need, if you get a condensed signature and you don't have the whole Merkle tree, you have to fall back to TCP to get the rest of the signature. VeriSign has documented their patents and licensing fairly well on the IETF's IPR page. I'm... I've made this bullet referring to SLDSA, SLHDSA in MTL mode. I assume that the... Their patents licensing will be similar for... With use with DSA, maybe Andrew will cover it later in his slides. Next slide. So again going through standardization regardless, yeah, it it would be covered by NIST standards. It can be deployed easily if people make the DNS protocol changes at the same time that they're make... They're adding the algorithm. The size of the records is mixed and the keys is mixed, as I said before, meaning small sometimes, big sometimes. It takes a lot of CPU usage to go through for validation, that may or may not become an issue. It requires protocol changes to do the MTL mode itself. It might become... Get into HSMs if it becomes important, and the assuredness is already extremely high. There is no question on the the hash part of MTL mode being at all susceptible. Next slide. So then there are others, lots of people have been proposing other signature algorithms, there's a bunch from NIST. China has its next generation commercial cryptographic algorithm program, So we we are not restricted to only considering the ones that I just covered. Many of those proposals actually are very attractive to DNSSEC because they are very small keys, signature or signatures and keys. So then in the case where you have a key that's only say a 100 bytes, then responses... I'm sorry, if you have signatures that are a 100 bytes, responses with three signatures in them such as an NXDOMAIN still will fit within UDP. However, many of these proposals have already been weakened in analysis. Some of the ones that people here in DNSSEC has said, oh, this one might be nice, has later been destroyed and taken out of of the the consideration. So... And that's my last slide. Again, I know I zipped through these really quickly. Hopefully, q and a comes later.
[00:14:58] Benno Overeinder: Yep. Thank you. Thank you very much, Paul. Then I'll ask, Bas to give his presentation. Right. Space desk. Confirm. Yep. That's the correct one. Success. Okay. First Oh, Bas, do you want to run it yourself, or shall I run it for you?
[00:15:17] Bas Westerbaan: You can run it for me. Okay. Thank thank you all for organizing this this interim. Next slide, please. As you might know, there's... A lot of people are concerned about deadlines that are coming closer with with with Quantum. But I'm not here to preach about Quantum or to convince you of it even though I'm, of course, convinced about it. Because the point is not what we think about it, but that people will come with questions. And what we need is... Next slide, please. Is we need to have a story for PQC DNSSEC, and at the moment, we don't have one. And I don't want to be facetious about it, but I don't care much what the what the story will be. Next slide, please. Well, I I do... I would like to have post quantum DNSSEC, but but I think the more important thing is not what is the outcome, but that there is clarity of what the path will be. Next slide, please. Because there's a lot of people now already asking questions of DNSSEC, and it will be more, and people will want to know what's up for for... And they need to have a around 2031 plan. Next slide, please. So now the question is not for me which answer is the is the is the best one, but I think the more important thing is which answer is easiest to check. Next slide, please. And I would say that of all of these m l d... Checking whether just putting m l d s a 44 DNSSEC will work, I think that's the most straightforward one to check and to eliminate if it doesn't work. Next slide, please. It is not very pretty. Here, you can see the result of a dig on a MLDSA 44 sign zone. Next slide, please. And it's also the one where I think we can we we can help with trying it out. So what we have done last month is we we got code point assigned for MLDSA 44. 1.1.1.1... 1.1.1.1 now supports it by default with domain protection. I'll talk a little bit about that later. We also support signing, but for now, it's an option because we don't yet know if it causes breakages. We set up some test zones on our DNS test dot dev. And starting today to actually... Because deploying this is nice, but to actually get insight into whether it works, we need to have a view from other sites. And one thing... One way we do that is that on challenge pages, that's on bottom right, you can see those annoying interstitials. They they annoy you, but they also have an advantage, which means we can run some some experiments to see whether things work. On these pages starting today, we're running on the one in a thousand. We're running a couple of background probes to these DNS test zones to see whether whether these big 44 signatures were breakings, most importantly, but also to see what the performance impact is. Unfortunately, we don't have the data yet because it just started. I hope Vicky will be presenting the results of the data in a month at OARC 47. Next slide, please. If it looks good, we'll roll it out by default. So when when people will turn up on the nest egg, they will also get dual signed MLDSA 44. I... It's it's it's it's it's probably it's probably not the best solution you can think of, and this is not the end of the story. We have 20 for 20 bites of motivation to do better, of course, but we need to have something. Next slide, please. On this list, I wanted to briefly say something about the better signature schemes, which Paul already addressed. Next slide, please. Especially in the NIST on ramp, there are some really appealing signature schemes. I like Mayo. They don't have that small signatures, though. But none of these will be broadly available. And with that, I mean, also with confidence in its security before 2031. And recent attacks on Hawk and SQISign, I think, underline the fact that that it's not just about not having the standard yet. It's also about not having had enough time to get certainty. I'm I'm sure that around 2031, we will know whether whether these schemes are secure or not. They will either be broken or we will have confidence to use them. Now that leaves Falcon FN-DSA. I don't expect... I would be surprised if there's a standard in 2029 given its complexity and the time it took with ML DSA. But... So, also, I wouldn't bank on FN-DSA solving things. Next slide, please. Now on the downgrades. Next slide, please. If we have a zone which is signed by both MLDSA and Elliptic Curves, for instance, at present, the recommendation in RC, I lost a number, is that a validator should accept any path. So what an attacker can do is that if you have a dual sign zone and you want a dual sign zone, if you want to give security to both classical and post quantum clients, then a man in the middle can can intercept the response and strip out the the post quantum signatures and forge the the elliptic curve images. This doesn't have to be on... This doesn't doesn't have to be a quantum attack on the fly. You can you can break one key in advance and then create vortures. And probably you want to do it high up at the at the root or the TLD. There's a easy fix, next slide, which is for a validator that if it sees a post quantum key in a DS record, then it should insist on seeing signatures for that algorithm as well. This does go against... Here's the number, RC684 zero's recommendation. Oh, and path, not oath path. Next slide, please. There's some references here. This is what I wanted to cover. Thank you.
[00:21:52] Benno Overeinder: Thank you, boss. Very nice. Very clear story. Then I'll ask Andrew to present the next desk. Confirm. Yeah. Also, Andrew, want to run the slides? Shall I run them for you?
[00:22:10] Andrew Kaizer: You can run them by now.
[00:22:12] Benno Overeinder: Okay. Thanks.
[00:22:14] Andrew Kaizer: Alright. Welcome, and thanks for organizing this interim. Today, we wanted to discuss how Merkle Tree Ladders helps address challenges created by PQC DNSSEC and merits consideration as one of the approaches that the community proceeds with for standardization around this topic. Next slide. So I believe everyone here today is familiar with the broad challenges we face. But for a quick refresher, DNSSEC currently uses RSA and ECDSA, both of which will be broken by a quantum computer. And we need to replace those with post quantum algorithms. Simple in theory, but DNS was designed to be fast and lightweight, and post quantum signatures are anything but lightweight. The replacement algorithms are dramatically larger than what DNS was designed to carry, so large that they may fundamentally change how DNS responses are structured and delivered. That tension between the size and challenges of post quantum signatures and the constraints of DNS infrastructure is the core engineering challenge we are solving for. Next slide. Time is not a luxury we have as we have heard, both in Paul and Bas's presentations. Now if we walk through this timeline briefly, in 2024, NIST published the initial round of finalized post quantum standards for key exchange and signatures 203, 204, and 205. That was really our starting gun as a community. Now in 2026, NIST has provided updates on FIPS 206, and as we have also heard, that's also gonna be several years away. And then, of course, the NIST on ramp process may or may not produce new algorithms up until around 2032. And we cannot really rely on these algorithms arriving on any particular schedule, so we cannot wait for them. And then, of course, in 2031, about five years from now, NIST will formally deprecate RSA and ECDSA. And then in 2035, they will be disallowed entirely in compliance systems. That's gonna be a hard deadline, and there won't be any extensions. And one more thing worth calling out that is not on the slide, the DNS root key rollovers require global coordination with IANA, with every resolver operator, with every registrar, and every DNS software stack in the world. This can take years, and the next one is going to need to introduce post quantum algorithms, so that process has to begin now. Next slide. To counter the PQC challenges we face, we need a diversified strategy. The points on this slide are not new, and they are based on the consensus established in previous PQC DNSSEC meetings as detailed in the draft on the slide and have been previously presented at the IETF. But it's good to see the community coming together around this strategy. That includes not waiting for the NIST on ramp to conclude before we move forward because we cannot guarantee the timelines will work out. And it does mean we need to work to deploy the currently standardized PQC algorithms because it's what we have available. We also want to continue to work towards the diversity strategy established at the PQC DNSSEC meeting. Namely, we want at least one conservatively designed algorithm whose security is based on long established cryptographic assumptions and, ideally, at least one low impact drop in algorithm whose security may be based on a novel cryptographic assumption. The low impact algorithm could be used as is, but note the tension we have already heard about today. No low impact option is standardized yet. We should be ready if or when one is available. For conservatively designed algorithms, on the other hand, options do exist, like MLDSA or SLHDSA. But their longer signatures pose operational challenges to the existing DNS infrastructure. Now fortunately, conservatively designed algorithms could be used in ways that reduce the operational impact. We also want to stress that operators should have a choice about which algorithms to use, which means support for multiple algorithms or versions with optimizations that can help reduce operational impact. Next slide, please. Merkle tree ladders is an approach that can reduce the operational impact of PQ algorithms to DNSSEC. Rather than signing individual messages, we can hash the message, which is relatively fast to do, and put them into a Merkle tree. We can then sign the roots of the Merkle trees with a PQC signature scheme. Individual messages can then be verified using the shorter Merkle proofs that is unique to each each message combined with the one PQC signature. The operational impact of the long signature sizes is therefore amortized across a potentially large message series, which is a good match for the DNSSEC use case, where we have a potentially large zone of DNSSEC resource records that can be protected with a given key. Next slide, please. MTL has the potential to offer many benefits for the DNSSEC use case, and we wanted to highlight a couple on this slide. First, it can conserve space required for each RR set because each RR set has a small Merkle proof instead of a large PQ signature, which minimizes impact on an authoritative server by reducing its own file size and using less memory. Second, it can reduce computation effort because there's only one large PQ signature that needs to be generated while the Merkle Proofs were created using quick hashing operations. And third, it can preserve bandwidth, especially if clients only need to fetch the large PQ signature periodically and can rely on smaller Merkle proofs otherwise. More broadly, MTL can help facilitate cryptographic agility because of these benefits. If an algorithm needs to be changed or if the key and signature sizes need to be increased, as we have seen in the past with RSA and ECDSA, techniques like MTL will be important to minimize the impact of these changes so we don't have to wait for hardware upgrades to double the system capacity. For example, if we have to go from MLDSA 44 to MLDSA 87 or switch to SLHDSA. The one PQC signature and related Merkle proofs really does help amortize the cost in a variety of scenarios. Next slide, please. Now MTL is not just a theory. And in support of the unofficial IATF mantra on running code, we have an open source reference implementation where you can find a suite of MTL, LDNS, NSD, and unbound in our Verisign GitHub repos. There's also a demonstration Jupyter notebook that has an interactive demo that helps show how the details fit together. Next slide, please. We also wanna briefly highlight that work and research on MTL is not new and has been ongoing as far back as IATF one seventeen. This includes inputs from a diverse group of participants and outputs that include open source contributions, presentations, research papers, and demonstrations. The work is ongoing, as it always is for the standards development process, but these inputs and collaborations have helped us improve MTL and led us to the drafts we have today. Next slide, please. The current MTL approach is split into two drafts, a base and an extension. The base draft defines MTL with MLDSA 44 and has each RR set response carry everything needed for validation using the zone's DNS key just like the existing DNSSEC algorithms and as proposed in the MLDSA draft. These changes are geared towards implementation simplicity while still enabling potential space saving benefits for operators compared to non MTL approaches. The second draft is an optimization that can further reduce resources by adding a signature tag to each request. This tag allows for network traffic optimizations because it lets a server determine if a query can be answered with a Merkle proof as the verifier already has the larger PQC signature. This also makes it easier for a resolver to only cache the short Merkle proof as it can tie them back to the larger signature and only needs to store it once. Our IPR declarations for the drafts can be seen on the links below. Next slide, please. These drafts can be viewed as providing evolving benefits over MLDSA 44. The base draft enables operators, particularly authoritative operators, to have a clear path towards resource savings compared to MLDSA 44. The authoritative only needs the one PQ signature and correspondingly smaller Merkle proofs, which achieve spacing computation saving benefits. However however, it still needs to send the one PQ signature with every RR SIG, so it will lack bandwidth savings. And for recursive operators, some savings could be achieved dependent on implementation, but the base draft also enables them to treat MTL as a drop in replacement and continue to validate in cache like they are doing today. The SigTag extension evolves the potential benefits into bandwidth savings and a clearer path for recursive resource savings as well. In SigTag, the clients will need to keep track of larger PQ signatures and encounters so it can communicate knowledge of them. When matches are found, less bandwidth is needed, and some traffic may even be able to go over UDP. Additionally, if supported, the SIGTAG logic provides a clearer path for recursive operators to track relevant signature data, which provides a natural opportunity to store the larger PQC signatures once as part of this implementation. Next slide, please. To reiterate, MTL has benefits that can conserve space, reduce computation, and preserve bandwidth. We certainly see all of this as a huge benefit, especially as a large registry operator with two of the largest TLDs. MTL also leads to energy and resource savings and provides optionality to operators. This optionality also supports cryptographic agility, as MTL can provide similar benefits for algorithms beyond MLDSA 44. Next slide. In conclusion, we are looking for support to adopt MTL for DNSSEC in an appropriate ITF working group that'll be working on PQ DNSSEC related work. The streamlined base specification provides an immediate path forward with some operational benefits, while the SigTag specification introduces optional but useful bandwidth benefits. Furthermore, results from our experiments shown at IETF hackathons and PQ DNSXI meetings have shown tangible benefits from MTL compared to alternatives. More broadly, adoption of MTL provides optionality to operators, a path towards cryptographic agility, and fulfills the strategy goal of at least one conservative PQ algorithm with reduced impact on PQ DNSSEC. Thanks for the time and consideration.
[00:32:14] Benno Overeinder: Thank you. Thank you, Andrew. I think there's been on the... In the chat a lot of comments and questions for... Well, in ten, fifteen minutes. Thank you very much for your presentation, and I'll go to the last presentation given by Paul Hoffman. There we go. Yep.
[00:32:37] Paul Hoffman: Great. Thank you. And, Ben, please run the slides again. This one will be a little bit faster because... So people have been saying, oh, you know, TCP fallback will cause problems for the authoritative servers and such. So I've been measuring that. Now just as a warning, I've been measuring a very narrow amount. These are preliminary results. I'll have fuller results published later. My intention is to not only publish results, but then when people yell at me and go, you didn't test this or you should have tested it this way, to actually iterate again. Next slide. So what I measured... And and again, it's impossible to say what a typical authoritative server is, which hardware it has, which operating system stuff. I just bought a $500 Intel based box, one of those little guys that a lot of people use for running home media, and it's running Debian and I put the, you know, four popular FOS servers on it. So there's three setups for each server. One is the configure, you know, the bare configuration that they normally recommend. I then asked all of the developers what configuration would they add to help TCP and then so... And that was a separate test and then the third test was taking that second one and adding some kernel tuning. Finding kernel tuning like generic kernel tuning turns out to be difficult, so I had to ask a bunch of LLMs and believe me, that was painful personally, but, you know, we have to do things to help the DNS. So the way we measured is we started... You... I use a kxdpgun from the Knot people. Thank you, CZ.NIC. I'm sorry. The, you know, the Knot DNS folks. And I kept sending more queries to the server until it dropped more than 1% of the replies. And the reason why I did this is that just looking at CPU load, you know, like is it at a 100 turns out to be completely useless. You could be at a 100% and still serving, and you could be below a 100% and still dropping a lot of queries. So we simply measured until it got to, 1% of the drops, both for UDP and then TCP, and then I took a ratio. So the idea is not how fast can this work because no one's probably going to run their authoritative server on the exact same box that I did, but it's useful to figure out how many... How much more will I be degraded by what percentage if I'm doing all TCP versus all UDP? Next slide. So as I said, I'm using kxdpgun from a separate box, so just to make it clear that this is good, I run it for ten seconds at a certain, you know, QPS and then look at what percentage of the queries were dropped. If it was below 1%, then I just went up by another increment. And I was doing this on a little local network with 2.5 gig Ethernet ports through a switch with nothing else going really on on the network. So for UDP, I increase the QPS each time by 5,000. So for example, looking at a piece of paper I have here, an untuned UDP one might be in the order of a 180,000 or 300,000 QPS. For TCP, because it would fall over quicker, actually increased just by 1,000 QPS each time. Next slide. So the preliminary results are TCP to UDP ratios were about 5% to 20%. So if the box could handle it for a particular name server with a particular number of cores in one of those three configurations could handle, let's say, a 100,000 QPS, it would most likely... Before it started dropping more than 1% of the queries, it would most likely start dropping TCP queries, you know, pure TCP traffic at about 5,000 QPS to 20 to 20,000 QPS. So again, different ratios for different servers, but that was not consistent. Certainly different ratios for different number of of cores. So as I said, this was an Intel box running with four cores. I then tried it at two cores, I then tried it at one core again to sort of simulate an... A more... A authoritative server that had other traffic on it. One of the results is that adding server configuration improved the results only a bit for some servers and not at all for others. So it seems like the servers are already doing TCP as best they can and as it turned out, using all the kernel tuning that the LLMs told me to, even though they told me different numbers, tried the lower numbers, I tried the higher numbers, it essentially made no difference at all. Running the same tests got almost exactly the same results even with kernel tuning. Yeah. Again, this is all preliminary. People might say to me after I publish everything including how I did all the tuning, oh, but you didn't try this or you didn't do that. And I'm... I will certainly retest and show. Last slide. So as I said, the the test box was an Intel box with four cores running on an AMD box, which has 16 cores. Of course, we got better performance, and, you know, the same cost of a box. Much better performance, but the ratios were about the same. And so I... And I couldn't do all the measurements, so I'm only focusing on the Intel box for the moment. We're gonna try to get better testing for the AMD box, but, basically, they were all still within that five percent to 20% range. As I said earlier, CPU load was an unreliable measurement, so I just didn't do that after a while because it was silly and obviously there's a lot more to be done. I will publish through the full initial results in the repo hopefully, within the next month or two. We're about to add some new hardware testing, but the intention is to have this all be open, possibly reproducible if you wanna spend the same money that we did on doing this. But if nothing else, people can say, hey. You didn't test this tuning. Can you do it and such? Okay. Great. So that's the end of this just so people have an idea that going to all TCP will degrade your box by somewhere between four and twenty times for, the ability to send back responses. Thank you.
[00:40:04] Benno Overeinder: Oh, thank you, Paul. Okay. This is the last presentation. I will... Already switch on camera. Thank you for all the presenters. So we asked... Was offered to kick off the discussion with a statement. And so we start the discussion with this this... Well, with the statement of Wes and then direct that discussion. But all the other questions raised with the presentation, etcetera, will get time in the next twenty minutes. So, yeah, thank you, Wes, and I will share your slides.
[00:40:44] Wes Hardaker: Thank you. Can you hear me okay? I'm... I had a communication failure, so this is my cell phone today. Sorry about that. Transportation failure this morning. So the end result, I think, as everybody just heard, right, we have to deal with this problem. There's just no way around it. You know, the options are are various. I think all the presentations today gave me hope in multiple directions, which is sort of the point of my slide too. Right? What what are we gonna do when signatures get large? And, obviously, stop using DNSSEC as one of them. I think that's, you know, out the door to to a large extent. You know, we can wait until PQC algorithms get small, but that's nebulous at best. So I don't think that that, you know, is one that I'm willing to, you know, take on personally. You could just require everything to use TCP. And as Paul just showed, there is some degradation. It's not as bad as I think most people were were thinking, but the the flip side of Paul's argument is there is an increased latency with TCP. And when latent latency is such a big issue, that that latency to do every request over DNS, which is what some people have suggested, just get used to it, suck it up, servers, you know, deploy new hardware at 25% more or whatever that might be as Paul's numbers sort of indicated. That's great, but but that's probably not what we want for the client necessarily. And then we can try and make the responses smaller, and that's sort of the Merkle Tree approach, you know, demonstrates a direction toward that. There's probably other things that we could do there too. Or we could stop requiring that we send so much traffic. And so one of my biggest pet peeves is that all of the TTLs out there for all the w w w major servers are often five minutes, but they're not actually changing in value, and the signatures have a seven day lifetime. So why do we need to resend all that information all the time? So to me, these are the three options that we have going forward, and we might wanna consider a combination of them. Or more likely, in my view, we should consider trying to handle all three of these potential directions. Gonna give a talk on on my do-nothing-new draft, but I won't do that today because we are out of time for the day. Benno, back to you. Did I lose out or did Benno lose out? I heard you asked on my phone, also on transportation challenge. Okay. Well, who wants to run the queue if Benno if Benno is missing? Ned, I think you're up. Or Paul could, but he's a secretary at taking notes. Okay. He's back.
[00:44:36] Benno Overeinder: Yeah. I'm back. So apologies here. And thank you, Peter, for filling in and, Shumon, please help me out. I don't know what happened. Network disconnection. I I don't know.
[00:44:46] Paul Hoffman: It it actually happened to all of us. It happened to all of us. So... Yeah.
[00:44:50] Peter Koch: Okay. Yeah. We only we only need to reconnect, and Wes just had finished his presentation, and we were starting to take questions.
[00:44:59] Paul Hoffman: Yep.
[00:45:11] Benno Overeinder: Yes, Peter. Please go ahead.
[00:45:13] Peter Koch: Yeah. So nobody else comes into the queue. So various thoughts. So first of all, thank you all for your presentations. Paul, on slide nine, mentioned the non miss algorithms, for example, the Chinese ones. I don't know very much about that. You said that that some of them have already been weakened or broken. So those, of course, are not candidates. But for the other ones, it would be interesting to have some sort of overview, so maybe we should see how we can get that for some next ITF meeting or something. Apart from that, as for how to proceed, my thoughts are that for now, I think it's good to go for MLDSA and make TCP work where it requires that. And TCP or a larger message transport is needed anyway for a lot of other things or some applications like PHP records, but I'm not saying that's the main motivation. But even if we use a different algorithm like FMDSA, it would be needed for DNS key and the next domain responses and stuff like that. So maybe starting with MLDSA now because we have that, it works well, and it is quite already vetted, Would be useful even if we switch to something else later because in the meantime, we'll have had a push towards supporting TCP better throughout, and that would make life easier. And so efficiency thing, the things like other algorithms or maybe MTL, we can always evaluate it. So so that shouldn't keep us from not exercising MLDSA and making large transports work. And about MTL, I have some concerns about how that works with online signing, but I don't think we have to address this now. We could start with a general solution, which ML-DSA already is. I mean, in the sense that works with online and not online signing, and we should continue on that route for now. And we can add MTL or something else always later. And then final thoughts. If we do this push towards TCP or larger transport, that might also have interesting implications and maybe developments around the deployment of encrypted transport because the queue for... Because the queue, for example, might help saving one round trip when using early data, and that could mitigate some of the TCP downside and some other computational trade off, of course. But it will certainly not hurt to see what happens if we do this. Thank you.
[00:47:47] Benno Overeinder: Thank you, Peter. Next in line is Paul.
[00:47:52] Paul Hoffman: Hi. Just a quick one on something that Peter said about the Chinese competition. So there are, like, 70 signature algorithms in the Chinese competition, so we don't want an overview of all of them. I haven't seen a reasonable overview from anybody. And then he was asking, well, how did they get attacked so quickly? Those people following the list will see that people are using the list to comment and and to... You know, when they have broken one of the the proposed Chinese out... Or one of the algorithms proposed in the Chinese one. So if you're interested in how signature algorithms break, you should definitely be following the list.
[00:48:41] Benno Overeinder: Hi. Hi, Stephen. Please go ahead.
[00:48:43] Stephen Farrell: So so I think I I I
[00:48:44] Bas Westerbaan: think I'm kind of, like,
[00:48:45] Stephen Farrell: really agreeing with what Peter said a moment ago before Paul, that going ahead with MLDSA seems sensible. Getting that to work better seems necessary. Something of the order of change like MTL, it seems to me that it will be much better to try and only do something at that level of change if you think it's gonna increase the deployment of DNSSEC generally and the security of zones generally. So doing it purely for optimization reasons doesn't seem justifiable given the level of deployment to DNSSEC, which is kinda not so great. So I think, yeah, more radical changes should be aimed at solving the major problem with DNSSEC, not not the consequent problems of for the tiny number zones who currently use cryptography.
[00:49:43] Benno Overeinder: Ben, please go ahead.
[00:49:46] Benjamin Schwartz: Hi. Yeah. So I find the, MTL work very interesting. I think that we we can certainly... And and and I think Will certainly push ahead in all of these directions at once. We have DELEXT going on, which is changing the the way we think about connected transports. We talked about TCP, but is going to change the way we think about DNS over quick, for example. We have MLDSA, in production to some extent. I think, I'm very interested to see, more feedback on MTL, especially from major, validators, people who are in the business of implementing DNSSEC validators, whether they have interest there because, I think we have we have clear... The the authors of the MTL proposals are obviously associated with a, a very prominent DNSSEC signer, but DNSSEC takes to to tango. So, if we have interest from both sides, then I think it would be very cool to see that move forward. There were some comments about MTL and online signing. It seems to me that online signing, even with the compact denial of existence, I think we're still talking about two signatures. So if you compare the cost, the size cost of two MLDSA signatures against the size cost of MTL even with some very generous signing limits, I think that MTL still comes out ahead. So online signing is probably both smaller and faster with MTL. But maybe somebody who understands that better can confirm.
[00:51:51] Benno Overeinder: Thanks. Thanks a lot. Karl?
[00:51:56] Karl Dyson: Hello. Yeah. I... So I was listening with interest there. I think one of my I'm I'm very interested, and thanks to to the folks that are doing the test on, know, how much goes to TCP, how bad is that kind of thing. I... We we run we run zones that are, like, dot u... The dot uk zones are changing on average once a second, and we're doing that all with dynamic updates. And so one of the things I'm interested in under... In understanding is, particularly when I when I listen and and and read about MTL, is how how well that works, I guess. And one of the things I wanna try and test is can I continue to make dynamic updates and use something like MTL, or do I need to go away and effectively redesign how I re? How I build zones? Because that's, like, a a lot of work. And, obviously, if we can find a solution or if we can find an algorithm that works for being able to continue to make lots of dynamic updates at quite a pace, then that's that's obviously preferable. So I'm kinda watching that space very carefully.
[00:53:17] Benno Overeinder: Thank you. Thank you, Karl. Next is Mukund.
[00:53:22] Mukund Sivaraman: Hello. So I suggest that we adopt Bas's draft for MLDSA. The reason is this, there's only considerable IP support everywhere on current operating system platforms. I think open system 3.5 supports MLDSA. So lot of DNS resolvers and doing implementations late to open open SSL, it's already there on existing systems. In case current computers break classical algorithms like tomorrow, we have a solution today. It's also... So we implemented in the ACL loop, our Bas's draft. And it's... I mean, so far, it's relatively very straightforward. It's just like dropping in any other algorithm. Like, implementing the CDSCO or implementing our SEO. So that's a drop in algorithm. There's no special construct necessary. It's clear. I mean, the issue is so there's no... Is this secure or not other than what the fifth standard already provides us. There is considerable signature sizes, but... Yeah. I I suggest we adopt Bas Westerbaan's draft. So to the minor points, I suggest question measurements of the kind of result of alternative traffic. There is kinds of result... Result of the alternative traffic at different large scale providers like ISPs and cloud providers. So the other class of what the traffic is like, like, how how would it affect the algorithm choices that we use? For example, from a recent article by Geoff Huston, root... Rooted TLD Ruta Jawale appeared in four... Even 5% of traffic. There's one go to a collective traffic. So that's something. And lastly, very high level point, simplicity and relevance may be better for us in the long term when we choose approaches rather than going for something comp... Complicated and, you know, lot lot of work, basically, because deals is already very, complex. Thank you.
[00:55:43] Benno Overeinder: Thank you, Mukund. Yeah. So I think one of your questions indeed about the type of traffic we see at the large resolver. So I understand that Bas is now measuring with his colleagues, so we will get an update during our work. Maybe I can ask Allison to do something similar for 999, but that might be a little bit too too optimistic. But we can discuss that with with p c... Sorry, with Quad nine and PCH. Yeah. Thanks. Paul?
[00:56:13] Paul Hoffman: Just another quick thing on what Mukund said that Mukund said that the working group should adopt the draft. There is no need for the working group to adopt the draft. We've already got an IAN code point. If there's any later work, it would be a draft that said, and we want the should or the must in... You know, to change or whatever. But at this point, there is no advantage to adopting a draft that says, here's a code point. It's out there. It's in the IANA registry already.
[00:56:46] Benno Overeinder: Yeah. Okay. Yeah. Yeah. True. And and, again, I'm not a crypto... Cryptographer. So it's good there. I see some people from the security area, and MLD is able... Is kind of fifth standard. So... And it's also used in other working groups. Besides your remark, Paul, I was kind of more generally asking, for this kind of... If you look purely at algorithms, is that something for DNS op or the DNS related, or should it be discussed in security area? But that's maybe something for for follow-up discussions. Where should some work, well, be continued? Is that DNS up, DNS, its area, or is it somewhere in the security area? But first, continue with the queue here. I think Ben is. Is that correct? Yep. Yep.
[00:57:53] Benjamin Schwartz: Just some some more lower priority thoughts. We've talked a lot about TCP and UDP performance. I want to put forward the argument that it doesn't matter, that when you are sizing a... Specifically, we're talking about authoritative DNS here. When you're sizing an authoritative DNS fleet for TCP or UDP, the cost of valid queries is not at issue. The size of the fleet has to be determined by Das defense budget effectively. And TCP, while it's more expensive potentially on a per query basis, has much less DOS abuse potential. A DOS attacker can turn on KXDP gun and fire line rate UDP at you from random spoofed source addresses potentially. And, you know, that's that's a a huge potential load. That attacker cannot do the same thing with TCP. They can fire those addresses from their actual source address, and you can block that one address. So, as a result, I don't actually think this, I I don't think that the authoritative fleet sizing issue is that much of a concern. Personally, I've been responsible for operating large DNS fleets that serve, you know, very, very large query volumes, almost, you know, majority over TLS, which is enormously more expensive than TCP. And it's just still not an issue compared to the other kinds of costs associated with actually running this, large scale service. So I think we don't have to worry too much about that. The latency, that, that we we heard about earlier, I think that's, much bigger concern. The other big concern that I really wanna focus on is Bas's observation about single valid path. I think, if we're walking into a future with more diversity of algorithms and it really feels like for the next five years, there's going to be a complicated mix of algorithms, and we don't wanna be having to ship all of them, and we don't wanna be getting the least security of any of them, I think we're going to need to do better than that. And I think that's going to require some changes to our validation rules or maybe even to the protocol.
[01:00:32] Benno Overeinder: Thank you. Yeah. It's it's time. Before closing, I want to first maybe ask... I see Matt and Deb is also still in the room. Yeah. So both the ice, the security AD, and the ops AD about future work. Matt. Yeah.
[01:00:57] Mohamed Boucadair: Yeah. I think you... If if this is related to DNS, I would say, deployment experience, the challenges or the problems that are encountered by people who are deploying this, and the hurdles, and this is something that can be really worth to be documented in DNS ops. So this is something which is definitely belonging to us. Discussing whether we can change, obviously, the recommendation in the current ENR history for the ML-DSA. This is something which is open for Denisop. Some things more specific, I would say, to the algorithms that's not itself. That's that's definitely out of scope of of our doing. So, yeah, there are items that that belongs to to here, but I'll let Deb further comment if needed.
[01:01:39] Benno Overeinder: Okay. Thank you.
[01:01:43] Deb Cooley: Deb Deb So as long as you are choosing algorithms that are well vetted and, are deployed in lots of places, then there's no reason not to do it in ops with some sort of security oversight, which I think could be easy enough. Right? When you start delving into things like new techniques, which I think the MTL is a relatively new technique, although it's related to some of the things we are already doing in security, then I think we need a little more... Maybe a little more touch. If you start going with Chinese algorithms, then I think you wanna engage more, more security, maybe even CFRG. But it just sort of depends on the path you choose. I am not I'm happy to have this happen in in ops with with some sort of, you know, at least just a touch. Right?
[01:02:36] Benno Overeinder: Yep. Thank you for your comments. So I want to close. I did hear some priorities. The... Well, I wouldn't... The MLDSA being out there implemented by a number of, well, resolvers, MTL modes, also having implementations, doing measurements, etcetera, but has more impact and, well, needs some consideration. Well, rephrasing the comments. So what's in in in size on... Well, in CPU memory and in message size, reply sizes. So I will summarize other... Well, the... Some of the notes I've made, the the the minutes, and we will... Of course, we can continue our discussion on the mailing list, and we also will come back at the the Dinasop meeting in in San Francisco. Thank you all. I think it was very useful, worthwhile to organize it, to kind of direct some of the work we have been talking about for longer time. And now, well, kind of steering it, make it... Make some progress and, yeah, and have PQ de de de sac in the in the... Well, before the before the thirties. I also want to acknowledge the PQ DNSSEC side meeting chairs, Peter Thomassen and and. Of course, they did for many years. I still do organize the side meetings. A lot of the discussions we have today also have been in the previous years at the side meetings, and they also helped organizing this this interim. Thank you very much, and see you online or in one half month. Well, just more than a month in San Francisco. Thank you.