Session Date/Time: 24 Jul 2026 12:00
[00:00:13] Brian: Look. The parental units are here.
[00:00:17] Duane: Are you talking to each other?
[00:00:40] Brian: Ready? Yeah. Alright. Good afternoon, everyone. We're gonna go ahead and get started. Welcome to DELEG. I'm Brian. This is Duane. We're your host for the afternoon. First of all, net wells, I everybody should have read this when they registered for the meeting. I think the key things here are to recognize that, you know, we do expect everyone to act in a professional manner, so, you know, make sure you're following the anti harassment guidelines. IPR, always a fun topic. Make sure you understand what you're what you're agreeing to. And if you have any questions, there's always documents that you could read that tell you all about the fun stuff. If you're in the room, you should be using the the on-site tool to make sure that you're registered in the meeting. If you're you're outside the room, feel free to use the full client so you can participate actively. And we just ask that every time you come to the microphone to speak that you state your name so that everybody knows who you are and the minute taking can accurately reflect your comments. Couple of resources for for this meeting. Hopefully, if you're here, you've seen this at least one other time. But if you have any questions, feel free to access any of these these links for information. Duane wanted to throw out that we actually got a mention in in the Pekka Kuchu the other night.
[00:02:28] Duane: Yeah. So if you weren't at the Pekka Kuchu session, do yourself a favor. And when the videos are released on the attendees list, take a look at Barbara's talk. Barbara's here with us today. Thanks, Barbara, for letting us share this. I understand that you made this by hand, so this is really great. Thanks a lot.
[00:02:46] Brian: Maybe we'll get this framed, we'll we'll hang it in the wall somewhere. So for today, a little bit order of business. We we have three topics on the on the on the agenda. What we're going to do, for those of you who don't know or weren't in DNS op, there was some some feedback that that came back from from the ISG on the Deleks document that has direct impact on the Delek document. So and you probably also noticed that there were changes made to the the DELEG document that was that was published recently. Because those changes weren't discussed on the mailing list, I wanna make sure everybody has an opportunity to understand what those changes are. So we're gonna start with talking about the the updates to the DELEG document. Roy is gonna give us some updates on the DELEX document. We're gonna stick a break in there and do the discussions of those two documents together because they are intertwined, and we wanna make sure that everybody understands what what the what's going on there. And then once that discussion has reached a a a conclusion, then we'll we'll go on to Paul's discussion of secure transports. Does anybody have any changes or updates they wanna make to this agenda? Okay. So the one thing that I will mention, Paul just sent an email to the to the mailing list. We do have a list of of implementations that are up in a repo on the work group repository. So if you have feedback on other implementations, you can you can go to there and and do a pull request in order to update it. With that, we'll get started later.
[00:04:44] Petr Špaček: Thank you. Can you hear me in the back? There were some complaints about the soft audio. Can you hear me?
[00:04:52] Duane: Maybe a little bit closer. Closer.
[00:04:54] Petr Špaček: Okay. I need to adjust this a little bit. Wow. How do I? I really want people to hear me. Okay. Is it better? Yes. Right. So oh, that's really weird to have Mike literally in your face. Never mind. My name is Petr Špaček. I will walk you through the changes to the DELEG document, and then the Roy will continue with changes to DELEXT document, which actually, like, are one protocol. So can I control the slides, or did I? Are you sure? Much better. Okay. So quick recap. We have bunch of implementations I'm ever at least of eight. LDNS is missing on the slide. Some of them are libraries like DNS Python, DNS Java, LDNS. Some others are author to the servers, namely bind of, what is it, Node DNS and Knot DNS and Akamai authoritative. We have a resolver implementation, which is only the closed source Akamai stuff. Plus Paul Hoffmann did his toy resolver to, like, experiment, and he didn't really cry. That's how it seems to work. I'm hearing in the whole ways that the PowerDNS is working on theirs, but that's, like, fresh news, so it's not really done. The most important bid here is that none of this was actually released. It's not in the main branch. You can find it in on the Internet, but it's not part of a release software because we so far didn't have the code point, so we didn't feel like, you know, squatting on a number in release software. With that in mind, it might seem that we are done, but we are definitely not. The main theme of the last couple of weeks or perhaps months was splitting the document into two, basically. The marching orders were, like, generic stuff goes to DNS op. So if the way to think about it is if in future we find out, okay, we've completely messed up the, like, version one, we need to do the, like, version two five sixty seven, then the generic bits shouldn't change. And these bits, which are how you sign and validate and so on, go to DNS op. The the like version one specific bits stay here with us in this working group. That's the way how we can think about it. And it sounds like simple shuffling text, really we fully messed it up, and I apologize because one I'm one of the authors. We had last call for the DELEXT, the DNS sub document that actually finished, and it seemed that it's okay. We had the last call for DELEG, which also seemed okay, but the catch is that most people are at only one the document and the other. And if you don't treat them in a lockstep, you don't realize that, ah, but this one actually belongs to this here because it's a generic bit, or, oh, this shouldn't be here because there's a specific bit, so it goes to the other document. And that's the main problem we have. The intention is not to change the protocol, please. We are just trying to make it right because we didn't change the protocol in, like, two years, the technical bits. Now it's like, you know, messing with the text and trying to get it right. Since version zero nine, which is the version which was sent to the last call in this working group, we've moved out roughly one tenth of the text over to the DNS sub document. And when I say one tenth, keep in mind that, like, half of the comment is examples and, you know, things which are not really normative, so that really doesn't matter much. So the normative part is, like, bigger than 10 of maybe, you know, maybe quarter is the normative stuff we've moved out. And namely, to give you an overview, it is the algorithm implemented by resolvers to find the delegation types. So that goes to DNS op. How the referral looks like on the when generated by after the live servers, what are the rules to send it over, and when the resolver can possibly accept this new kind of referral that goes to DNS op as well. DNS ex signing, validation, and protection against downgrade attacks. Again, this is generic, not specific for for the, like, version one for lack of better term goes to DNS op as well. While doing so, the text had to be a little bit generalized because when it's at, like, delek in capitals as an other type name, that needs to be replaced with a branch of types, delegation types as where it calls them. And, you know, different authors different sets of authors want to do things differently, so the text is a little bit different. Some pieces of the original text state with us in this working group along and they are basically sort of examples or guidance how you implement the generic protocol from DELEXT specifically for DELEXT version one. So it's like, we have removed the normative language so there is, like, no risk of, like, trying to overwrite what DELEXT does and, you know, turn it into sort of an example. If you are the like ever and this is and you get referral, this is what you do. Blah blah blah. Again, all the normative stuff should go to the next. We had some other changes like new examples for escaping because that's always a pain point. Right? We had to fix one of the examples for del x because there was an omission. We were missing an NSEC record. An example, they fixed that. Power DNS Folk actually contributed test vectors for the key equals value encoding of the parameters that is very useful. I've checked before merging it into the document that it matches exactly byte for byte what bind is doing and what the DNS Python is doing. So at least three implementations agreed. Hopefully, that's good enough for not putting a wrong example in there. We removed bunch of to dos, which were, like, all over the place, and some of them were like, ah, someone needs to check this. And that was, like, removed with assumption that if no one yelled up until now, that's good enough. Some of them were moved over to del x and solved in del x in DNSSOP, so easy as that. And some were actually done, like, clarifying what happens if you have parent and child zone at the same server and you query for delec without the beta and blah blah blah. So there is these were, like, little tweaks. They they were not, like, normative language. Just more examples and things like that. Awarding I mean, there's no need to explain that here. You know how IT works. Security considerations is the probably the most interesting bit where some changes happened. The text which went to the last call had an instruction that I call it as list duplication, but an example. You are a resolver. You've got a delegation with referral. The referral has 100 names. All the names resolved to the same IP address. So what the text said and still says is that you must not try 100 times the same IP address because it doesn't make any sense. Some time has passed, so now we can disclose that if you don't comply, you will end up with a CVE with this nice number or you can get your own if you want. Another change was that we had in one place, we said, you must not do more than three layers of indirection. And that's, to the best of my knowledge, the only place in the all of the DNS specs which had, like, one hard coded numeric limit in the spec. So we removed that with the assumption that if people are after, like, hard coded numeric limits, then they go that group of people can go to DNS op, which has draft-fujiwara-dnsop, DNS upper limit values, which has, like, you know, 20 more things which can go wrong, which you have to limit anyway. And they specify, like, the useful seen today value sort of in the draft. So if there is a demand for hard coded limits, please go to DNS op with that. The downgrade protection was in the security considerations. We've basically removed it, and the only thing which is left is, like, a section title and one sentence which says go see the DELEXT document because, again, this is, generic downgrade protection mechanism. It's not specific to the, like, version one. So what do we do? Well, preferably, we get some more implementation feedback because you have seen that all the implementations are basically old. They were done, like, year or more than a year ago, but we've significantly changed the text with the intention of not changing the protocol at the same time. So it would be really nice if people can go through it, preferably while implementing it for the first time and, you know, implement the version 11, then we can see if it can actually interpret with the version with the implementations built on version eight or 10 and see that the text actually makes sense. Of course, there will be you know, ITF is in the business of producing documents, so we will be tweaking words and things like that. So what's next? Please, please, please. Review both documents at the same time. This is very important because it will hopefully help us to avoid the mistakes we've made in the past. So read them in lockstep as it was as if it was one document altogether, and tell us this doesn't make sense. You know, this they're like reference to the del x is completely wrong because you have completely wrong section number that might easily happen because these are just literally numbers and things like that. So, please, I can see someone in the queue. I'm done. Alright. Roy.
[00:15:22] Duane: Yeah. We're gonna do questions after the next presentation. So
[00:15:41] Roy Arends: Next deck of slides, please.
[00:15:43] Duane: I'm working on it.
[00:15:49] Roy Arends: Alright. So Roy Arends, I can. To be honest, I wrote my slides, while not having seen Petter's slides because we finished basically late last night doing all the changes to both drafts. So whatever Petter said goes, there's some evolution bits of how we got here. It's not really important right now. Since the IETF last call for delegation extensions, included various text. This is what Petra alluded to. These were present in DELEG. We've now moved it to DELEXT. Added some clarifications that I missed, wildcard expansion and q type any. Wildcard expansion is definitely interesting because it relates to delegations, and you can't have wildcard expansion with delegations. So I missed that. I've added that. Change processing of the ADT flag. You think it's a big thing, but it's actually not as important. You need to check the ADT flag at one point, and it's more efficient to do this the moment you cache than than every time you are processing a Deluxe record. Our good friend, Schumann Hoch, this week noticed some issues with compacting out of surface, ROC. So we, both Pat and I had to look at the at the changes we need to make. We put that in. And then also this week, we met with the chairs. They were, interested to see what was going on, and the area directors. We explained the work that was done over the last couple of weeks to make the split, actually work. To be to be honest, it was it was it was a lot of work, and and but I think I think we got there in the end. And delegation extensions now covers, as you've heard before, the modifications to to make to make the range work, and normative language relating to service resolvers, validates, etcetera. Thanks to Philip Homburg. Philip, where are you? Oh, he just left. Oh, smart of him. So Philip Homburg at one point said, yeah, all of the security section is nice, but what's the threat model? And I realized we didn't have a threat model. So I wrote one, and I've added that to the document as well and made that clearer. Also, the IANA requests are mostly now in the delegate delegation extension. I'm talking about the ADT flag and the DE signal. That's now in in I mean, they're they're absolutely identical in both documents, so that shouldn't be controversial. And and DELEG, as you know, now covers the DELEG type, the r data stuff, values, etcetera, examples, everything that was already there in DELEG for DELEG specifically, that's still in there. Almost verbatim, the the last slide of better, delegation extensions and DELEC are complementary, and they should be reviewed together. I understand from the area directors, they're push back the the documents to the working group. So future last calls should be done together. I trust that it will happen. The reason it's gonna be pushed back naturally because documents both document changed so much, it wouldn't be fair to just not do a last call again. So that's where we are. Thank you.
[00:19:20] Duane: Yeah. Peter, go ahead.
[00:19:22] Peter Devoy: Yeah. Hi, Peter. Alexis Power, DNS. I had been nerd sniped last week into trying to implement this because I was reading the draft. I have some wordsmithing things for Delext. I'll put it on the mailing list. One thing I would like to ask the chairs in the working group is to mandate a implementation status in the DELEG document and not move forward with the last call before there are at least two implementations that can interrupt for servers, resolvers, and validators. Because we're it's it's pretty the the the server part is and the R types are relatively easy to implement, but I do think a lot more testing has to be done on the resolution part. I don't think it's wrong, but we need to be sure that this works very well before we move this forward to a last call.
[00:20:17] Duane: Yeah. Peter Peter T, go ahead.
[00:20:19] Tomofumi Okubo: Tomofumi Okubo. Hi, Peter, Thomas, and ISC. So, the two drafts are two separate drafts, and, originally, they were combined. And there is a lot of work that went into splitting them. It should be reviewed together. I just wanted to recognize that the split, I think, has led to important insights. For example, the modified behavior for ADT use from Donald's review. I just wanted to recognize everyone's work that went into it, and I think it's good that we did the split.
[00:20:48] Florian Obser: Flo, and I'm so happy to see two points. One, at some point so I contributed this text about resinfo, and this also came up with the the next x draft that if you're talking to a forwarder, you need to be aware if the forwarder actually supports this. One problem with that is that we will be stuck with that flag forever. And so if we're continuing adding stuff to resinfo, that thing just gets bigger. I wanted to think a bit more about that, especially if we need to if we if we figure out, oh, DELEG is actually not working, so what Peta was talking about, and we need DELEG version 67, then we need a flag that tells us, oh, we are supporting all this stuff, which is going to be very annoying. The the other thing is about reviewing the draft in in lockstep. I was wondering if there's not supposed to be an order again to what what Peter said about if we're messing this up. So should DELEG stand on its own? Like, I'm reviewing that one first, trying to understand that that thing is actually internally consistent. And when I'm done with that, then I'm reviewing DELEG.
[00:22:09] Roy Arends: So this is not guidance. But if I were to review these documents, the idea and, Petter, correct me if I'm wrong here. Delegation extensions, the stuff you need to implement to make the entire range work, needs to stand on itself. It's not dependent on DELEG. DELEG has references to delegation extensions in order to make DELEG work. So if you wanna put an order on that, that's the way I would review it.
[00:22:35] Florian Obser: Okay. Yeah. That's also how I understood it.
[00:22:39] Roy Arends: Don't let the don't let the bad text and delegation extensions discourage you from reading delegation from DELEG.
[00:22:47] Petr Špaček: I want to add that in lockstep doesn't mean, like, necessarily, like, mesh it in your head together and, you know, exactly as well, etcetera. The the imagine that first you read DELEG, DELEXT, and then say, okay. So do I know how would I create the, like, version two and then perhaps redo version one? But maybe it's asking too much from the reviewer. I don't know. But perhaps think about the, like, version two after you are done with reviewing the, like, I don't know. But the the idea is that you rip out the DELEG version one, what we have now, and try to reimagine, you know, something else. Yep. Some other which would use the same or let me rephrase in another terms. The idea is that now we are doing lots of work on the protocol. Sure. But for this to be actually useful and deployable, we have to change the authoritative servers. What is it? Signers, validators, and resolvers, basically everything. But this is this should be if if it were tried and if DELEXT is correct, this should be like one time investment. And then if DELEG version two comes around, then we need to change only the resolvers. Resolvers would need to implement new pieces for the like version two, but the authoritative servers, signers, validators should stay the same. So, basically, DELEXT is this part, which should be always the same, and the, like, the command is the things which you can change with any of it.
[00:24:24] Paul Hoffman: Paul Hoffman, two things. One, to feel like the old guy in the room, but if you print out both specs and you pull out a pencil with an eraser and you jump back and forth and such like that, it might go better. But the main reason I had actually put up my hand was to comment to Peter Devoy. We have been doing testing already. We do already have interopulate. Doesn't mean that we interoperate with this. So I certainly intend to in my toy app, toy resolver application, after doing the review again, I'm gonna go through and look at my code or the the DELEG specific code and make sure it matches and then run them again. But the message that I sent to the mailing list about twenty minutes ago reminding folks of the page that we have, those all have worked together already. I am not concerned about interop now. If we hit some interop bumps in the next couple weeks, boy, will that, I would say, then we really need to stop and you two need to, like, figure out which that is. But we have been testing all along, and we've actually done very well. I don't actually remember any tests where somebody said, I'm not working with you, and one of them had to change their code to do it. It worked pretty directly the first time for me.
[00:25:47] Petr Špaček: I will add that for the testing off of the dev side, I think that we are more or less covered because I've personally tested bind, no DNS, and the Akamai author that they've, like, altogether, and they produce, like, the same answers for and my test set has, like, over 2,000 query combinations, like different flags, different types, different labels, and things. So I couldn't find any any disagreement on how they respond, which doesn't necessarily mean that they are consistent with what the specs us. Right? But at least the implementations agree in what they generate today. What we don't have is the resolvers, and I agree with the argument with Alexis made that it would be nice to have resolver to play with. Yeah. And you've mentioned one other thing. What was it? Never mind. Maybe it will come back if oh, yeah. Pants on the printer, but that printing it out and trying to match text will be fun. Enjoy. But it is it is necessary. I mean, that's what we were trying to do for some time, but I think that offers kind of suffer from tunnel vision, and it really more eyes on it would be good. Ah, yeah. I I now I know. You've mentioned that we are, like, exceptionally covered. I wanted to emphasize that from me as an implementer perspective, I don't really care if it has RFC number, like, tomorrow in, know, three months. I need the code points, then I can release the stuff, and then we can get, like, some more experience in it, like like, actually put it on the Internet, play with it a little bit, and then declare, okay. We didn't really couldn't find any difference. It actually works. That's fine with me. But without the code points, really, it's kind of hard.
[00:27:44] Duane: Peter, I know something you've been adding more and more recently is examples to the document. Are you looking for people to help you verify that the examples are correct?
[00:27:55] Petr Špaček: Oh, definitely. I mean, I think that, like, 50% of examples is in DNS RFCs are wrong. If you look for erratas, very, very often they are for the examples. So please have a look if the examples are correct because I was fixing one like yesterday, and the example was there for two years, so there might be more bugs. It's sometimes you can, like, run the code, but some of the examples are, like, failure cases where it shouldn't work. And we just demonstrate if you do this, it will explode, hopefully, in controlled way. And these are, like yeah. Think about it. Read it. And implement the excellent.
[00:28:36] Peter Devoy: Hi. Peter Devoy. PowerDNS again. Based on what you said, would it make sense to have a full zone in the in the draft that's alongside all the different options or all the different responses that you could get from an authoritative so people can test against that? So you will know that every server will do exactly the same thing. Just just an just an idea. I'd be willing to contribute something in that matter.
[00:29:05] Petr Špaček: Personally, fine with me if we if the working group is okay with having, like, appendix with 100 pages because it will be a lot. We say that's okay, we can, like once we have the implementations which actually agree, which we do have for the after that if servers, I mean, it's kind of easy to generate because we have the code. The code generates exactly the same answers, so it's quite likely that this doing what it should be doing. And, you know, we can, like, have a script, generate all the combinations, and here you go. But, again, it will be 100 pages.
[00:29:39] Peter Devoy: So, Yeah. Yeah, that's a question for the working group. Would they work
[00:29:41] Brian: with us?
[00:29:41] Petr Špaček: I don't know. I've never seen it in RFC, which doesn't necessarily mean it cannot be done or should not be done, but I don't know.
[00:29:49] Duane: Okay.
[00:29:55] Paul Hoffman: Another option, instead of putting in the RSC, is to put it on the on the GitHub repo that we have because that will live beyond this. We could we and if we don't wanna have it all there, we could put it there, and then other people could do the tooling for how do I send the queries and such whatever they way they want. We can throw up a Python script for doing it or Go script or whatever. So that's another thought if we don't wanna stick it in the RFC.
[00:30:21] Petr Špaček: Yeah. That also works. I mean, I, you know, I'm I enjoy breaking stuff. So having test vectors and have the ability to play with it is all fine with me. If you say that the RFC appendix is not the right place, fine with me. I don't insist. It's just having more testing what basically Peter Devoy demands sounds like a good idea.
[00:30:45] Peter Devoy: Also, sticking it in the RFC makes it forever Yeah. Instead of an in a GitHub repo.
[00:30:52] Petr Špaček: That might be also bad if we do it incorrectly. As of yeah. Yeah. Yeah. That is always always change of this. Okay. Thanks. So who is going to review it? One more time, please. Can can we get some some volunteers? That's not enough people. That's like four hands. That's not enough. This is like for next twenty years. Please, please. How can I make thank you? Okay. Thank you.
[00:31:23] Duane: And I have a request for the authors. So there's been a lot of activity this week, and everyone here in the room knows about this. But I think people on the mailing list may be a little bit out of the loop. They're not here to see this. So if you could post a message to the list about basically summarizing what's in your slides about the changes you've made recently, that would be good. And then I know Roy wants to ask me
[00:31:47] Roy Arends: a leading question. Yes. So Peter alluded to this before. We need a code point. And to understand a code point allocation I I happen to be one of the, expert reviewers. That doesn't mean I'm an expert. I just was one of the last ones to step back when they were looking for volunteers. But, once you ask for allocation of a type, it goes through an expert review. One of my colleagues has reviewed it and give some feedback, and I think you were the one requesting the the early allocation type. Maybe you can allude to what happened.
[00:32:19] Duane: So we, as the as the chairs in conjunction with the Dino sub chairs, we made requests to Ayanna for early allocation from five different registries. Three of those are completed now. One of them that's not completed yet is the res info key that's waiting for a second expert review. And then the two RR types are not completed yet, and Tommy sort of has the action item on that. He's going to write something up and get I s IESG approval and send it to Ayanna to hopefully complete that final step, and we'll get those RR types allocated.
[00:32:58] Roy Arends: Actually, update. Alright.
[00:33:02] Brian: So I'm gonna ask Paul to come up so we can talk about secure transports, but I do want to reiterate what the plan is going forward. When both of these documents are ready for working group last call, you'll see a single email from one of the one of the chairs. We haven't figured out which one yet. Probably an arm wrestling contest to figure that out. But it will be a a working group last call on both documents to both mailing lists. So the comment should cross populate. And, you know, like we were saying earlier, read the DELEXT document, read the DELEG document, and think about them as as as a pair that need to be in in step with each other. So, hopefully, that won't that process will get started soon, but be be prepared for for that call coming out.
[00:33:56] Paul Hoffman: Let's talk about the future. So oh, here. I can just do this. So secure transports has been talked about as a use case for Delegate for quite some quite a long time. And, basically, you know, since we know that some authoritative name servers want to run either DOT or DOQ or both, and they want to be able to announce it instead of having people probing all the time and saying, oh, are you doing secure now or not? It would be nice to be able to do that during delegation discovery. So when you say, what are the authoritative name servers, for example .com, not only do you get where to go, you get sort of a how to go there as well. And and and that would be, like, either DOT or DOQ. And so Delegate is well set up for that, and that was one of the things from early days is the Delegate is extensible, so let's just do that there. And so we I we did a draft. Ralph and I did a draft with three new delegate keys to go along with the current set of delegate keys. One says secure transport whose value is either a d o t or a d o q. One is no d o 53, which says that the target it's telling you know, during delegation, it's telling you that the target does not do d o 53, which sounds weird. It is weird, so it's not likely to be used for a long time. But there are use cases that we have heard where people say, I don't want anybody coming and getting this data insecurely, and therefore, we're telling them this is the only way to do it. And then there's also a key type for TLSA, which could is actually the certificate or the key that you can use to authenticate the DOT or DOQ. So that's pretty much it's not a long draft. It's pretty basic. And we announced it in May. You know, we put it on the list. People had said, deleg, delex, we're getting mature. Let's start this. And we got almost no, you know, response, which is okay. You know, we're not, like, up there rushing it yet. And and, again, it's not even a working group document. But we do want review at some point, and soon is good because we're not even sure if this is the right design. When Ralph and I were talking about it, we had a couple no. No. Like, one of us was one way and one of us was the other. We came to agreement. We're perfectly happy with it, but others might not be. And, again, it's a short document. Is it too short? Is it too concise? Especially when we're talking about how do you authenticate, we are not being prescriptive at this point because this is not a group who does authentication very well. So just to be clear, we're not expecting any implementations at this point. Let's get deleg, dellext finished and such like that. But at that point, we know that there are plenty of authoritative servers out there that are experimenting with DOT and DOQ right now. If you go and probe on 443 on 853 and such, you can find them, blah blah blah. Let's be able to start working with them. And that's it for what I have.
[00:37:27] Brian: And they're all named Peter.
[00:37:30] Paul Hoffman: Peter. And they're all named Peter. Cool.
[00:37:33] Peter van Dijk: Peter one. Hi. Peter van Dijk. PowerDNS. The document is not too concise. I love it. It's the perfect after lunch read. I have one question. Will there be a way to mandate web p k PKI certificate checking?
[00:37:49] Paul Hoffman: If you going back one. If your if the value in TLSA is a certificate
[00:37:58] Peter van Dijk: that is Yes.
[00:37:59] Paul Hoffman: But And that certificate was gotten by WebPKI or the DNS PKI or the government PKI, then that's not mandating. What it's saying is this is the only way I'm telling you you should authenticate. You can't mandate anything. People can make authentication mistakes in many different ways. We have thirty years of examples of this on the web.
[00:38:24] Peter van Dijk: Yes. But there's no syntax in TLS a to say just do anything from the WebPKI.
[00:38:30] Paul Hoffman: No. There absolutely is not because there isn't a the WebPKI. For those of us who are not sitting in TLS at the moment, we know that in fact, there's the CAB forum, there is the ones used by Chrome, there's the ones used by Firefox. High overlap, not a 100% over.
[00:38:49] Peter van Dijk: Yeah. Not correct. But there's
[00:38:50] Paul Hoffman: there's a Venn diagram. It's not a circle.
[00:38:52] Peter van Dijk: Okay. There's some wording in the draft that suggest you could use the LSA to specify such, but it's it's a small detail then.
[00:38:59] Paul Hoffman: Okay. If I said that or if we said that it's wrong, all we're saying is either this is the key to use or this is the certificate to use.
[00:39:07] Peter van Dijk: So chain to it. That's right. Okay.
[00:39:09] Paul Hoffman: Exactly. Again, it's a certificate and it happens to be in your view of what the WebPKI is, great.
[00:39:16] Peter van Dijk: Yeah. Yep. Got it. Thank you. Thanks.
[00:39:22] Peter Devoy: Hi. Peter Devoy. PowerDNS. Also, really enjoyed the document, nice and short. I do not fully agree with the design because the no-do53 makes no sense to me if we re we could rename secure transport to transport. And if do53 is not listed there, you shouldn't use it. I think that is a a a much easier design in in in the grand scheme of things because you you don't need two keys for that. You could just have one key. And if it doesn't list do53, then just don't
[00:39:52] Paul Hoffman: Oh, okay.
[00:39:53] Peter Devoy: Two fifty three.
[00:39:54] Paul Hoffman: This is exactly where Ralph and I were yelling at each other. So when we when this ends up being a working group item, if it does, that's a perfectly reasonable thing to do. And we can we can map out both of them and and see if yeah.
[00:40:07] Peter Devoy: Yeah. Excellent.
[00:40:08] Paul Hoffman: This is logically correct in some ways, but it's also more verbose.
[00:40:12] Peter Devoy: Yeah. Yeah. So I'll I'll I'll go on the mailing list for this because I read it yesterday evening. So Great. This was the first thing that popped into my mind.
[00:40:18] Paul Hoffman: Great. Thanks.
[00:40:20] Roy Arends: Hi.
[00:40:25] Shane Kerr: Shane Kerr. Peter? Call me Peter for this
[00:40:27] Paul Hoffman: discussion if you want. So
[00:40:32] Shane Kerr: maybe maybe Peter's discussion or suggestion suggestion obviates mine, but there's there's no way to say please don't probe. Is it?
[00:40:42] Paul Hoffman: Okay. No. No. And, again, because even if we had a way to say please don't probe, please is a really weak word anywhere in for
[00:40:50] Shane Kerr: a resolver operator to not waste time on that. Right? Correct. So if we may but if we make it an explicit list, I'm declaring something only use these, then that's implied, and that's good. Okay.
[00:41:01] Paul Hoffman: Yep. Exactly right.
[00:41:06] Florian Obser: I'm not Peter.
[00:41:09] Paul Hoffman: But you could be.
[00:41:10] Florian Obser: I could be. Yes. And that would probably even be the correct pronunciation. Anyway, I disgrace. Authoritative nameserver operator, sometimes snarky. How do I use that for, you know, my authoritative nameservers? And hint, I'm talking about the root.
[00:41:26] Paul Hoffman: I'm sorry?
[00:41:27] Florian Obser: How do I use this for the root nameservers?
[00:41:29] Paul Hoffman: We don't at this point. We don't have a way of because Delegate is always in the authoritative. There is no authoritative for the roots. Indeed. And we we figured this out
[00:41:40] Peter van Dijk: Yeah. That
[00:41:42] Paul Hoffman: I'm sorry. There's no parent for the root. Yes. Right.
[00:41:44] Florian Obser: Yes. That and and we figured this out that we can't actually do priming queries with this thing, and then so we kicked it down the road. And now it turns out we can't do crypto transport and we're kicking it down the road.
[00:41:54] Paul Hoffman: Right. So are you suggesting that we do that here or that there's another document that is about, you know, parent like Deleg for the route?
[00:42:07] Florian Obser: I have no idea. Okay.
[00:42:09] Paul Hoffman: I have I have multiple ideas as I just said. So and give me give me five more minutes, and I'll have the third one. But yes. So I hear what you're saying, but you're not asking us to put it here is what I'm saying.
[00:42:22] Florian Obser: No. I don't.
[00:42:23] Paul Hoffman: Okay. Great. Okay. Good.
[00:42:27] Tomofumi Okubo: Hi, Peter. Thomas in ISC. So I think this draft is an Wait.
[00:42:30] Paul Hoffman: You're Florian?
[00:42:30] Duane: Oh, no. Sorry. No.
[00:42:31] Tomofumi Okubo: I'm Tomofumi Okubo as I sometimes get called in emails. Anyway, so I think this draft is an almost obviously good idea, so we should do it. But I also dislike this designer symmetry with a no do53 and then the list of secure transports. So either that could be as I think somebody make a list of transport. It could also be Booleans. And so, for example, the do53 could by default be true, the others be false. And if you specify them explicitly, you can override them or something. I don't know. I don't care. Maybe the list is better because more
[00:43:01] Paul Hoffman: Guess what doesn't have Booleans?
[00:43:04] Tomofumi Okubo: SVCB doesn't? Oh. Oh, then I'm I had some wishful dreaming in my mind. So Ralph and I
[00:43:13] Paul Hoffman: had put booleans in, and then we were looking, and we were like, oh, we just spelled out the word t r u e.
[00:43:23] Peter Devoy: A quick quick comment on that. If you're really concerned about that, the DELEG draft has DNS names for SVC params, which is also not specified.
[00:43:33] Duane: So,
[00:43:34] Paul Hoffman: you know? Let's not go there. Like Yeah.
[00:43:36] Peter van Dijk: Exactly. But, I mean, just specifying a zero or a one would be fine. Right.
[00:43:40] Paul Hoffman: And it's better we we we, as we were thinking about it, decided that zero and one would be better than t r u e and f a l s E because what about capital character? So we will figure this out. Oh, I'm sorry. You will figure this out as this comes to the working group. Ben?
[00:44:00] Ben Schwartz: Hi. Ben Schwartz. So I'm so I'm a little disappointed, as I said before, that we don't seem to be maintaining parallelism with SVCB here because it means that we are going to have to reproduce an encoding for encrypted client. Hello? We're going to have to reproduce an encoding for the new TLS supported groups extension. Every time TLS comes up or Quick comes up with something that they wanna do with SVCB, we're gonna have to do it again here. But, it seems like the working groups has consensus to to do that. Okay. My my main point here is to say, I I think this is a fine starting point. I have a lot of different concerns with it, and I wanna know where to send text.
[00:44:53] Paul Hoffman: I don't know. I would say wait until it's been adopted by the working group, but then it would be in the working group. You would send it to the working group.
[00:45:04] Peter Devoy: Okay.
[00:45:05] Brian: So so, Ben, let me let me even though we haven't done a a working group adoption call for this, I don't think it's it's problematic if there was discussion of this document on the mailing list. So Paul Paul did post the Yeah. So I I'm I'm fine with with the discussion going on in the mailing list even though it hasn't been adopted yet.
[00:45:27] Ben Schwartz: Alright.
[00:45:34] Paul Hoffman: Who is number two? Another pattern.
[00:45:38] Petr Špaček: Sorry, Nick. I forgot.
[00:45:42] Paul Hoffman: You forgot that you were a Peter?
[00:45:46] Brian: Florian.
[00:45:49] Duane: Skip the queue if you want.
[00:45:55] Florian Obser: So the pitchers are giving up now. Florian again. Two two random thoughts. So about the booleans, you just put in a deal 53 equals Norway. The more serious one is I I think in the DELEG yeah. At some point in the DELEG draft, we had wording that this is not for the root. I don't know if you still have those words. Oh, well, if we had them, then maybe it would be worthwhile to put it here to explicitly say this can't possibly work. Okay.
[00:46:20] Paul Hoffman: Well, it can't be for the root because it's not in the parent.
[00:46:24] Florian Obser: No. No. I understand that. What I'm saying is when when we pointed this out for the DELEG draft, we actually put words into the DELEG draft. Hey. So that this doesn't get, you know Yep. Argued over and over again. Right.
[00:46:35] Paul Hoffman: Okay.
[00:46:38] Petr Špaček: Reacting to Florian's concern that this is not working for Root. Well, the thing is that today, three solvers have hard coded IP addresses. Right? That is basically equivalent of HINTS file. So one way to look at is is this. Now we need a new HINTS file format somehow, which might be the, like, records, like, in the HINTS file. I don't know. But, basically, something which can express, okay, you can do TLS to, you know, k root or whatever. Yeah. But I'm saying that it doesn't really matter what we put in the DNS itself because DNS is always are not looking there anyway. They are looking at data. They have hard coded in the binary on in file on disk. If we wanted to make it work with priming, that would be different discussion because then we need a place where to put sort of equivalent of the like param and say, well, it can be possibly the like param on the root itself and then instruct resolvers. Okay. So go fetch dot the like param and use that as to result of priming so that it's a possible solution. I'm not seeing the right one. But that would be, I think, different document again because it's more generic. Right? Even if we don't go to if we ignore secure transports, the priming question stays for route. Because if if you wanted to go and specify DELEC for route, even without a secure transports, well, why would you? But if you want it, you can't. And the priming question is the same regardless of secure transport or anything else we do. So I think that separate document about priming might be in order, but I don't know whether we want to go there because the route I mean, now or in this decade. Because the route will be the very last one to move anyway, and possibly, we'll never do DOT. I don't know. So perhaps it's like putting horse before the cart or how you say that.
[00:48:41] Florian Obser: To react to that, that's good. To to react to that, I I think you said there are no root names servers that do DOT. Well, there are. Well, I don't.
[00:48:58] Petr Špaček: Oh, let me rephrase. The this secure transport draft helps you if you don't want to probe. Right? And most importantly, if you don't want to be sub I will rephrase. You need this draft only if you want authenticate. If you are going to do not authenticated TLS, then, I mean, go have fun. You can do that today. The the main value of this draft is that it allows you to actually have the secure connection somewhere. And if you want to have secure connection, then kind of the fallback goes out of the window. Right? So either you are proposing well, now we are doing TLS to root, like, all the time, and we need to authenticate or we don't need it. That's what I'm trying to say. Because with probing, anyone can do that. I and if I'm, as a result, we're willing to talk to Root over DOT today and just, you know, have it for fun, and if it doesn't work, fall back to port 53, then you don't need any delay. It's like, you know, one if in the code, you give it a try and then fall back to port 53. So either we are serious about doing authenticated DOT or whatever route, or we don't need it.
[00:50:19] Ralf Weber: Just to on on one pattern. I mean, even if you don't want to authenticate, you need this draft for the parent to give you a signal to try and transfer. Because, again, one of the reason I stated this a lot in other working groups, I don't wanna probe willy nilly. I wanna probe if someone gives me a signal. And this is also you need this draft for.
[00:50:45] Roy Arends: Eric?
[00:50:47] Eric Nygren: Eric Nygren. Yeah. I think it's this is important to get in because I don't I think we want to have people who have explicit control over things, especially operationally, people may want to not have things trying to probe before they're ready to do it, because otherwise, it makes the introduction order tricky. But I think this is a good start. As I was noting in the chat, we went through this node 53 style thing when doing SVCB. And where we landed there was basically the same sort of thing of having kind of an implicit entry on the transport list and then having a way to say, no, actually, I don't want to do that. And that was from a safety perspective because people thought that implementations would want to fall back to the safe thing anyways without a, let's say, explicit signal of no no really. It might be here that since this isn't something entirely new, that we could we could make the opposite decision. But if we want to keep parity, kind of this sort of model make kind of at least aligns with what HTTPS did.
[00:51:49] Roy Arends: Mhmm.
[00:51:51] Paul Hoffman: Great. So now we're getting Eric's instead of Peter's. Right.
[00:51:54] Eric Osterweil: Oh, Eric Ostrall. That was gonna be my joke.
[00:51:58] Paul Hoffman: So Okay. Sorry. I cry shenanigans, but whatever.
[00:52:02] Eric Osterweil: No. This is small comment. I read through the draft, and I noticed that the TLSA is encoded in TLSA format, so it's the actual TLSA. But since you can specify a dot and a doc, is it worth the having a way to address the complexity of what if I need to have two separate keys because I got two different secure endpoints and they might not use the same service?
[00:52:24] Paul Hoffman: You could have two of these records. Right. And then I do you want
[00:52:28] Eric Osterweil: to leave it to the client side to say, I guess I'll try on both, or do you wanna play it? I I'm not saying I have an answer, and I'm not saying it's bad. I'm just pointing it up.
[00:52:35] Roy Arends: It might
[00:52:35] Eric Osterweil: be worth looking into.
[00:52:37] Paul Hoffman: I thought about that, and it made my head hurt, which doesn't mean it shouldn't be in here, but we didn't we didn't go there yet. And and I think I think the fact that now your head's hurting, I I think we should address it in in the document.
[00:52:49] Eric Osterweil: Scalability if there's three or four.
[00:52:50] Paul Hoffman: Okay. Doctor Wright.
[00:52:53] Ralf Weber: Answering, Eric. I mean, you can have two different RRs, as as Paul Paul said. And the thing is that anything that you have in this RR only applies to the server or the IP or anything that you have in that RR. So and with resolvers, I mean, they'll do whatever you give them. I mean, so they're the belief that you can influence what they do is, I think, not founded in kind of experience.
[00:53:23] Paul Hoffman: I I think the word in English is hilarious.
[00:53:30] Petr Špaček: That Right. Is but check. Resolvers like to have local policy as we call it in IETF, which means, well, they they build whatever they feel like, and I forgot my point. There was something else. Never mind. It's Friday afternoon. Right. You we understand. Right.
[00:53:48] Paul Hoffman: So I've got a question.
[00:53:51] Petr Špaček: You're not in the queue.
[00:53:53] Paul Hoffman: I feel like I'm in the queue. I feel like I'm number zero. So a bunch of people brought up the the question of the root servers. I have thought about this, and I have no idea whether it would be in here or in DNS op because in DNS op, we have this document on priming, of which I'm one of the authors. And so some people said priming, some people said, oh, it's not priming. It'll be somewhere else. Can you folks, when you're having these two long conversations with the DNS op chairs anyways, put this in the queue? Because I do think this will keep coming up. I think the question of, well, why didn't you deal with the root servers? You know, could you do it like this? Is going to be a constant question, and there are two ways to do it. We either do it in the priming document, and we say, here's additional priming information, which might look like a Deleg param, or we do it in Deleg where we say priming is done. Priming is just priming. It's always gonna be over d o 53, but there should be a Deleg param for the route that someone would know to look for even though it's outside of the protocol and such like. So I'm just asking you folks to queue that up because I believe that will be coming. Fortunately, no one here said it should be in this draft. So yay. But the things in this draft are already relevant to the row back there where we've got a couple root server operators who are already running DOT, DOQ. And I think that there will be more who wanna do it later.
[00:55:37] Brian: Are are you talking about the three people who are ducking down right now?
[00:55:40] Paul Hoffman: Yeah. Exactly right.
[00:55:43] Brian: Yeah. We will we will include that
[00:55:44] Paul Hoffman: in the conversations. Eric?
[00:55:47] Eric Nygren: A quick on a slightly different topic. On the TLSA one, the have you thought on whether it would make sense to have a have that be the a name for the for TLSA RR set instead? Because I think one of the things we're as things wanna do wanna do rotations and as PQC means with these these get much, much bigger, it may be safer to to be able to to separate them out either sometimes or or always rather than trying to have kind of trim the whole thing into this service params, especially if there's reusability across
[00:56:20] Petr Špaček: So to
[00:56:20] Paul Hoffman: answer your question, no. I hadn't thought about that. I don't think we should be the ones to think about that. If we wanna reopen TLSA, that's fine. And, remember, you can put a hash there. TLSA can you you can do you can do full or hash of the cert or the public key.
[00:56:43] Eric Nygren: But this is in particular pointing to the ARR set of TLSA records. Like, the the name of having the TLSA service param be the instead of the actual inline t TLSA record, be the name of ARR set.
[00:57:01] Paul Hoffman: So you want indirection here as well?
[00:57:04] Ralf Weber: Yeah. Similar to include parents.
[00:57:06] Eric Nygren: Sadly, yes, which could be which could be something like dot saying just use this use this use my owner name use my owner name for it.
[00:57:13] Paul Hoffman: I had not thought of that, but it seems like Ralph has.
[00:57:16] Ralf Weber: Yeah. I mean, it is a possibility to do that. We probably wanna have a different kind of, like, parameter for that. But we need TLSA because otherwise, we have the same problem as with the regular DELEC. You cannot kind of, like, bootstrap it without. So it's a possibility, but it's an addition if we do it.
[00:57:36] Paul Hoffman: Yeah. So yeah. So when this comes to the working group, maybe we will add that in direction. Add it, not replace.
[00:57:45] Shane Kerr: Yes.
[00:57:48] Petr Špaček: The only problem which cannot be solved by adding another layer of indirection is too many layers of indirection. So RFC nineteen twenty five. The question is whether we should first, before introducing another indirection, do some proper analysis and think if the DNS the DELAC include or it provides the facilities. Because if you say, okay. I have this cluster of, like, million domains on the same name servers, and I want to put the fingerprints in there. There is no reason to copy them million times for every single delegation. You do include dash the, like, param equals somewhere else in the tree. You put that set of servers along with the fingerprints and everything in one place, and you update it in one place. So maybe another layer of indirection is not needed. Maybe. But I would say before rushing to add that, we should, like, analyze whether the DELAC include can be used for that purpose because we hope that it will work.
[00:58:51] Paul Hoffman: Yes. So I think what's coming out of this discussion is this draft will become less concise, but hopefully still concise. Cue is done. Great.
[00:59:10] Brian: Alright. So that is the end of our official agenda. Does anybody have DNS related topics that they wanna talk about since we have thirty one minutes? Going once, going twice, going Alright. Thanks, everybody. We will be doing those working group last calls as quickly as possible. Discuss the secure transports document on the mailing list, and we will see you in San Francisco.