Session Date/Time: 21 Oct 2026 20:00
[00:00:37] Pete Resnick: Would someone care to speak so that I can check my audio is working?
[00:00:42] Richard Clayton: Yes. Of course. Of course.
[00:00:43] Pete Resnick: Excellent. Check one, check It required a little reboot, but that is just fine.
[00:00:57] Richard Clayton: You did, however, echo back to me, so you may wish to make sure you're muted when anybody else is talking.
[00:01:04] Pete Resnick: Yeah. I will turn myself down a bit. Getting assorted windows open, ready to go. Did you enjoy my exceedingly boring slides there, Murray?
[00:01:58] Murray Kucherawy: I was just testing to... That I had control. I did not review them. I figured you've done this before.
[00:02:07] Pete Resnick: As boring as they usually are.
[00:02:17] Murray Kucherawy: I think when we get to the point where we can recite the note well, literally, from memory, it'll be time to retire. Do we wanna get rolling, or should we wait for... We have... I see six people participating right now.
[00:02:51] Pete Resnick: Yeah. There... There's a few cool kids, but maybe give a minute or two more. Alrighty. I was kinda hoping that Wei would also be here.
[00:03:02] Murray Kucherawy: At least for his part of it.
[00:03:04] Pete Resnick: Yeah. Well, you know, Richard Richard's got the slides. So Okay. Well, I think it's about time.
[00:04:28] Murray Kucherawy: Alright. Would you like to drive, or shall I
[00:04:31] Pete Resnick: I... I'm happy to.
[00:04:33] Murray Kucherawy: Alrighty. Way. Either way, I'll I'll drive slides. You drive speaky things.
[00:04:37] Pete Resnick: Well well... Welcome to our exceedingly boring set of slides. It is virtual interim time again. So do remember this session is being recorded, so don't say anything you wouldn't want your, you know, mother to find out about. Next slide. So this is the note well. Everybody who is participating in this room has agreed by dint of participating that you are going to follow the IETF policies, processes, and procedures. This is particularly important with regard to the anti harassment policies and the code of conduct. If you are not aware of them, please make yourself aware of them. You should also be aware of IETF intellectual property rights and the issues surrounding those. If you are not aware of them, you certainly want to read the RFCs involved. There are RFCs twenty twenty six and twenty four eighteen, which describe the standards process and working group guidelines. And, again, note that there are recordings of things, so please be aware of that. Next slide. So, for remote meetings, please turn off audio and video unless you are presenting or speaking during q and a. And and at that point, you are welcome to turn on your video. We'd love to see your smiling face, but you are not required to. If you've got a headset, please use it because it will lower the chance of echo and feedback. And if your name is not perfectly clear on the little icon in MeetEcho, please state your name so that we know who you are. Next slide. If you would... And actually, if I were smart, I would have pasted this into the chat. There is a note taking tool if folks would care to scribble down some notes that will help us when we do the minutes. The meeting materials page will have the slides available, and you can take a look online for those. And of course, there's the working group main page, which has our documents and such that we're going to be discussing today. Next slide. Here is our agenda. We just got done with administrivia. We're gonna have, yeah. Go ahead, Murray.
[00:07:27] Murray Kucherawy: I I just... I have one one or two pieces of administrivia. One thing is just to confirm with everyone, there will not be an interim between now and 01/27. We we can't... I don't think we have enough time to produce proper notice. So this will be it until we meet in San Francisco. The other thing, I just went through the the milestones, which were quite stale. I have marked two of them completed and one of them deleted, which were... Like, the motivation draft is no longer something that we're planning to pursue, I believe. I marked completion of the adoption of the base document and the DNS document, And, there's one remaining milestone, which is, to send everything to the IESG. It's... It was one milestone, so I left it as that. But I changed it from November of last year to March of the coming year. I just made that up for the most part, but if anybody wants to... So there's two things to talk about. Is is that a reasonable target? We can always adjust it later in in consultation with Andy. But we also could break it into pieces and say we're gonna send the base document separate from the DNS document, separate from the VCP document. So, we don't have to decide all this stuff now. I just wanted to tell the working group what I had just done. And if if anybody wants to screen that that was absolutely the wrong thing or there is another way that we should arrange these things, this is a good time to talk about that.
[00:08:43] Pete Resnick: Excellent. Anybody have a comment on timings and and etcetera? And I apologize for my flashy video. I don't know what's going on. It's it's fun machine day here in Illinois.
[00:08:57] Murray Kucherawy: It's a red alert for the PHP hack that just came out. Thank you. Ah. Ah. Ah. Yes. Yeah. Yeah. Yeah. Yeah. Yeah.
[00:09:03] Pete Resnick: And and the TLS certificates that that more hacked too. Yeah.
[00:09:09] Murray Kucherawy: There's no... Nobody rushing for the mic, it seems. So what I did at least didn't upset anybody, and I guess we'll just leave it that way and maybe talk about it at 01:27.
[00:09:16] Pete Resnick: Sounds good. Yep. So agenda for today, other than what we've just talked about, we've got the main document up for discussion, which Richard's going to go through some open issues and some things that got changed recently that need a little explanation. And at the end of that discussion, I'd at least like to hear among this small group whether we think we're ready for working group last call. Murray and I, for the past, I would say, few weeks, had been saying, you know, it's looking like it's time to pull the trigger on this thing and and send it off, because it really does look like it's coming in for a landing. So we'd like to hear about that. Then Richard's got some slides on the post quantum stuff. I expect Richard and Wei will talk about those, and we will talk about the DNS document at that point, I presume. Bron had some slides on implementation notes. Yay, Bron. And yay, Claude. But glad to see those, and that might also lead to do we wanna put some of those implementation notes into either of the documents. Those won't be published, but they may be useful for, IESG review. And then we'll leave some time for any other business. Anything else need to be added to the agenda? Todd, were you itching to talk about the BCP today or anything?
[00:10:54] Todd Herr: I was not. Any itching I'm doing any itching I'm doing is unrelated to the BCP.
[00:11:02] Pete Resnick: Well, thank god for that. And they have creams for that too. So...
[00:11:07] Todd Herr: Yeah. Yes. I I understand that, but I am at least tangentially affected by today's PHP fun and frivolity. So I've got nothing to say about the BCP.
[00:11:17] Pete Resnick: Alright. Then we'll hold off on that until, at least 01/27. Alright. Well, with that, Richard, the slides are yours to share. If you wanna bring them up, or one of us can do so and then pass control to you either way.
[00:11:35] Richard Clayton: I I think you'll need to bring them up. There's too too many icons here.
[00:11:44] Murray Kucherawy: One moment. Do you see those?
[00:11:49] Richard Clayton: Yes. I can.
[00:11:50] Murray Kucherawy: Okay. Then call your... Call it. I'll change the slides as you go.
[00:11:55] Richard Clayton: Okay. Let's have the next one then. Okay. Right. Over the past... About the middle of last week to... Through many early hours of the morning and well into Sunday, I foolishly talked to my friend, Claude, and said, this document here, is it consistent? And Claude said, no. And I also said, well, actually, I have some guidance that people would like to be a bit more clear about what local policy meant and where you had freedom to change things and where you didn't. So I spent a considerable amount of time writing more text, getting it reviewed, rewriting it, and getting into the position which I I shipped as version o seven. Basically, a key thing which is different in o seven from the earlier drafts, and in fact, different from Dkim one as well, is that there are a large number of musts and a very small handle number of mays, but I don't think any shoulds at all now on what a signer has to do. So, basically, the spec ties down what you have to do in order to sign a DQIM two message. And a verifier has pretty much no must at all, but what a verifier does is it produces a report, and it tells you whether or not a message is, what in the jargon of the document is, a validly signed Dikim two message, which has lots of capitals in there because it's in the glossary, and it actually really means something. And the document is quite clear what that means. As a and it basically means what it says there, which is it's a Dikim two message, and there's nothing wrong with it. And if what you have in your hand is a message which is not a validly signed Dikim two message, then you should not give it to strangers who might take a look at it and say, that thing you just gave me is not a validly signed Deakim two message. If you want to do something with it all by yourself, you may do whatever you wish. I do not care. Right? The verifier, assuming you implemented according to the advice that you are given, will correctly determine whether or not what you have is a validly signed Dikim two message or not, but that's all it does. Now if you actually look at the source of that, you'll find there's a whole pile of shoulds in there, and the shoulds are entirely to do with how... If you're going to generate message... Standard error messages, which you may attach to your reports if you tell people what you thought of their message. You don't have to, but you may use the standard messages. And if you do use those test... Standard messages, there are some shoulds as to how you should adapt them for filling in the things in angle brackets into actual bits of text from your message so that people understand your messages. Now the other thing a verifier can do is it can tell you whether or not a message is in the jargon again, so capitals, provisionally verified, which... And a provisionally verified means that a very first glance over it says that it is it is the top level... The the topmost DQIM two signature and the associated message instance work that they... That it's correctly signed. So the difference between provisionally verified and validly signed Deacon two message is the provisionally verified you just you just accepted that the previous person has sent you something where all of the signatures and the hashes work. Validly signed means that you've gone back across all of the record of where the message has been and how it has been modified, and everything checks out. And there is a valid chain of custody, for example. The point of this is that if you get... If you decide a message is provisionally verified, then you can accept it. You can close the SMTP conversation, and then you can take a a deeper look at it and then decide it's not a validly signed Deacon two message, at which point you can reject it with a DSN, and nobody will... The person who gave it to you will be the correct person to give that DSN to, the delivery status notification. And, essentially, what this is is this is taking some concepts which we had written down before as local policy and spelling it out and explaining what the limits of that local policy are in terms of what local means. And, essentially, if it's not properly signed, you can't give it to strangers, but you can do anything you want. I shall stop there in case anybody is going to say, very good, Richard, but that was a waste of time because we don't want it like that.
[00:17:09] Pete Resnick: There was some chitting and chatting on the mailing list already. Everybody is comfortable with the way this is? Go ahead, Allen.
[00:17:29] Allen Robinson: So I I I like the philosophy a lot better. I will... We'll start with that. The the must not send along to other systems, I'm not so sure that works in the adoption the adoption phase where you're... You get a message. It's not valid Deakim two, but you decide to do something with it anyway and forward it because you suspect that it's just transiting some non Deacon two sender or intermediary rather. So I think that might need to be softened a little bit. I will admit... I haven't read this version of the spec yet, so I'm I'm just working off of this description.
[00:18:19] Richard Clayton: Okay. Well, I must not send it to strangers. In fact, what it says is you must not sign it.
[00:18:25] Allen Robinson: Yeah. That... That's probably fine.
[00:18:33] Richard Clayton: So we we we can... Certainly, I I think you should read the text as it is and see whether or not you wish to fiddle with what you can do with a not validly signed. But, basically, the the the bottom line is if you give it to somebody else and they check it, they're gonna blame you. So don't sign it because then nobody knows you touched it. Wei?
[00:18:55] Wei Chuang: Yeah. I haven't also... I'm I'm a bad person. I haven't read zero seven close enough to fully understand what provisionally verified means. But, and if... My first question is, can you describe some instances that help distinguish provisionally verified from validly signed? And my second point was just simply for the authentication results, can we find a code that describes this in some way so that, you know, people who get such a message in their inbox can look and see, oh, the Deacon two verifier said this. Maybe it could be done by pass versus policy. I don't know. But, anyways, just something that helps, like, distinguish those scenarios that can be materialized outside of the verifier. But, yeah, if you could distinguish validly signed versus provisionally just to help to
[00:19:51] Richard Clayton: decide. The easy way to think of it is provisionally verified, the topmost signature and signature and hashes work. But when you look at it, the chain of custody is wrong and is broken, so somebody has forged it and given it to you. The way I've originally verified it's useful is that you can shut the SMTP converse... Conversation. You can then have a deeper look at the message, and then you can decide it's not validly signed. You can then decide what you wish to do with that. And one of your options will be to give it back to the person who gave it to you. If you can't do the provisional verification, which doesn't just... Which also involves checking the mail from receipt too, then you can't be sure that you give it back to the right person. You'd be back in in the world of backscatter, so you should... So you can't, then you can't then generate a DSN if it wasn't provisionally verified. Now if you don't want to use provisionally verified, you want to... Whilst the SMTP conversation is still open, you want to do all of the, checking that you need to do in order to be absolutely sure that this is valid from one end to the other and everything is just fine, then by all means, do that. Then you don't have to worry about the provisionally verified state. What you write into the message when you give... When you do something local and you... You're basically applying your local policy, which is I don't care what the verifier thinks of it. I'm gonna stick it in the mailbox anyway, then it is open to you to use authentication results for that. Bron has a draft, which will give you some strings that you can put in there, and the the o seven mentions that as being a possible way that you might wish to annotate the the mail in order to drop it into your... Into a mailbox. And in particular, if you add authentication results, then since that is not a signed header, it's not going to affect any further checking you wanted to do.
[00:22:11] Pete Resnick: Everybody else good? Anybody else actually read the updated draft? Go ahead, Emanuel.
[00:22:30] Emanuel Schorsch: Yeah. So a a couple thoughts. One on kind of what Wei and Allen were just talking about. I I do wonder how that will handle the intermediate cases. I'm curious to see what Bron's update is for the authentication results, but the specific use case I'm thinking about is what exists today for... And I know ARC is, on its way out, but the use cases that ARC is handling in terms of intermediaries, either, you know, university alumni's, privacy forwarders where they are currently ARC signing that, and it has some authentication results included. And so I think that use case needs to be supported, so I wanna see what Bronze... How this interacts with it because the must not for sending it along, I feel like you don't wanna lose... It is useful for them to still be signing with their Deacon too, but in a way that it is clear that it passed through them in a verifiable way, but they are not the original author. So
[00:23:28] Richard Clayton: I'm I'm here to tell you that if you have a university alumni forwarder, the chances of your message turning up either provisionally verified or validly signed are nil. It's not a Deakim2 message, and you should not expect it to handle it as a Deakim2 message until that alumni folder is enhanced.
[00:23:51] Emanuel Schorsch: Right. But I think I think that's a problem because, I can just attest that this was a big issue, for example, deploying no auth, no entry. And one of the things that was very helpful was using ARC. And so we turned down ARC for valid reasons, but I think it is important that Deacon two serves as a partial replacement of of that use case, because otherwise, I think it is going to be a world of pain, and it's going to extend the adoption phase because it's going to be much more difficult to handle those kind of partially broken cases.
[00:24:26] Richard Clayton: Well, there's two observations I would make to that. First of all, my day job does the author entry or says it does as well. And we did a certain amount of work with ARC, and we've turned most of that off because it didn't actually help us stop any bad stuff. And it let through a lot of bad stuff, which otherwise we would have blocked because the people who signed putting the auth... The ARC headers on were not actually telling us what we needed to know. And the and the second observation is that if you haven't written any code... I mean, this is gonna come up several times, I think. If you haven't written any code in the last year, then you do not understand quite how the landscape has changed with things like Claude code. Right? There is... If you're gonna say, oh, it's gonna take us ages to rework that, ages now means all morning. Right? The mod... Modern tools for updating a soft web... Your software code base are extremely fast, extremely accurate, and and extremely correct in producing you what you need to do. Provided you steer it in pretty much the right direction, provided there are high quality documentation, and that's one of the things that, I I would claim o seven now is, then you will get a really good working system out of it, and it will take you longer to deploy it than it will to write it.
[00:25:55] Pete Resnick: Bron, we're a small enough group that if this... If you're in the queue to answer this question, jump in.
[00:26:04] Bron Gondwana: Sure. Oh, wow. This light really is bad. There's no point forwarding authentication results because the only things they contain are SPF or Dkim two checks. And the Dkim two checks, you can do yourself. There's no point trusting anyone's earlier Dkim... I mean, there's no there's no downside to including them either. But once it's... Once things are Dkim2, the authentication results are something you can always calculate yourself. In terms of the alumni forwarding issue, there's basically two things. Right? There's other senders Deakim two signing in the first place, and then there is is the forward of Deakim two... Adding Deakim two as it forwards. And so if if something comes in non Deakim two and you added Deakim two yourself, you can do that, but the from alignment won't be there. So you need to from rewrite, basically. I have some things that do that. That's nice and clean because the from can be undone by the eventual recipient to see who was really from, in a reliable way that before you would... You do use heuristics. So the alumni forwarder will have to get dkim2 in fairly early for that. And it can then... Something that comes in unsigned, it can from rewrite and sign, and something that doesn't come in... That comes in signed had better be right. Otherwise, why is it forwarding at the first place? So I think that answers all the use cases there. Yeah. Certainly, way that I've done that for for list stuff is if you rewrite the message, then it's okay to stick a a first Dkim two on there and say, originated this and here's here's a rewrite for how to get it back to what it was when I received it.
[00:27:45] Emanuel Schorsch: That makes sense to me. I think the the... I still feel like it... That's not clear in the spec, especially with the must not. But maybe I'm not reading in the right way. Like, do you feel like if that's clear in the spec right now that as long as you rewrite the front header, it's okay to stick your Deacon two on it?
[00:28:03] Bron Gondwana: Richard, what do... What would you say to that?
[00:28:08] Richard Clayton: Provide you remove previously Deacon two history. If it's come through a chain of Deacon two stuff, and then it's... The chain is gonna break at you. But but I'm not sure you're talking about it because because it came from Deakim two and your
[00:28:20] Bron Gondwana: Deakim two aware. It didn't didn't carry Deakim two, but... And you are Deakim two aware, then you can you can put a first Deakim two signature on there, so long as you rewrite the from address.
[00:28:32] Richard Clayton: Yep.
[00:28:33] Bron Gondwana: And you can still have a message instance that includes an undo recipe to give some previous state on that first dkim two signature that you signed.
[00:28:42] Murray Kucherawy: Yeah. So you're purely...... What back?
[00:28:45] Richard Clayton: Oh, sorry.
[00:28:46] Pete Resnick: No. No. I... I'm purely an editorial question then. I... Because... And and maybe this is more for Emanuel. You know, does this belong in the spec, or does this belong in some sort of operational statement in the BCP of here's how you're gonna use this thing. And I I could be convinced either way, but I I think it's worth attempting to decide that here.
[00:29:11] Bron Gondwana: I think so long as the spec says that you can have an undo recipe which changes the from that's before the first signature. Yep. And I'd have to check the exact text to see that it says that that would be the only only thing I'd take out of this is make sure the spec allows for that.
[00:29:31] Richard Clayton: You you can have recipes at hop one. Right? We did that specifically so that you can check it. The the argument was that maybe there was... Behind that was the valid design Deacon one message, and then you could apply some heuristics. You're back in the world of trusting other people, of course. The the recipe they put in is correct, but that is your local policy. And because the message was... Will be validly signed Deakim two message at the point of which you get it with the with the mangled from, then you're perfectly free to give it to somebody else if you wish.
[00:30:09] Bron Gondwana: Yeah. While we're talking about this, sir, there is one thing that maybe isn't quite so clear. What about if your Dkim two signature is message instance two and message instance one also exists? Is that still fine? It's the first signature. It signs a valid message instance. Is there a requirement that the first signature is the first message instance or not?
[00:30:31] Richard Clayton: No. No. And there there is not a one to one relationship between Deakin two messages, they can go in either direction. And that's the one... Wonder of nd equals, which you'll see in a moment.
[00:30:44] Bron Gondwana: Yeah. My my Claude was a little confused about that, but I told it I told her it was fine.
[00:30:52] Richard Clayton: Well, I I much rather you told me what he was upset about, and and Yeah. I can I can fix it?
[00:30:59] Bron Gondwana: I will do so. Alright. I'm done.
[00:31:05] Emanuel Schorsch: Yeah. I think I think that answers, my question, and I agree that, like, the description of of what is the proper way to do that if your forwarder belongs in the BCP, not in the spec. I'll maybe propose just, like, a slight tweak to the language. I think just the the language of must not send it on is is... I I continue to misread, and I think that there are use cases where, you know, a broken Deacon two comes in and you want to send it on, kind of as Allen mentioned. But I think maybe making it clear that you must not send it on without removing the chain.
[00:31:38] Richard Clayton: Well, if if you if you send it on and and you start again from scratch, I I I can... Well, you must see what what is written there because there is some... There's a little bit of discussion what it is. The the must not is you must not extend the chain when when it was when when it was broken before. Mhmm. Right? So what you are doing is is... Doesn't... Is not caught by... If you start again from scratch, you are not doing what you're often written from doing.
[00:32:14] Pete Resnick: And this is just me speaking from the floor, and and I agree that I think that text, covers it reasonably well. But, you know, if people have suggestions, definitely Yelp. I posted in the chat purely editorial, and and, you know, you went to the bother of changing all of these labels. But it seems like validly signed sounds more like the provisional thing, which is you're checking the signatures and validly chained is what you're currently calling VSDM. And I... And if you called them foo and bar, it still wouldn't make any difference, you know, to the actual outcome, but your call. You are the editor on that.
[00:33:04] Richard Clayton: I'll see if I can find something which says totally valid from one end to the other, Deacon two message, which isn't very long. Would you like pucker?
[00:33:17] Pete Resnick: Exactly. Alright. I'll take myself out of the queue. Anybody else on this topic, or is Richard set to move on? On you go, Richard.
[00:33:33] Richard Clayton: Okay. Another slide then.
[00:33:36] Pete Resnick: And and... Oh, Emanuel turned off his video. Good.
[00:33:40] Richard Clayton: Okay. Right. Okay. If you read the document, you will find that the concept of a relaxed domain match is now extremely clearly specified. Before,
[00:33:53] Pete Resnick: it was
[00:33:53] Richard Clayton: a little sloppy, and my claw had a had a real go at me about how sloppy it was. We actually use relaxed domain match in four different places, and exactly what we feed to it and in which order because it's not a symmetric match. The the the match does things to one of the two arguments in order to try and strip labels off it in order to cause it to match with the other one. And, therefore, the order of what what things are fed differs. So you will now find if you read the spec,
[00:34:28] Todd Herr: and always a good idea to do
[00:34:30] Richard Clayton: that, then you will find that it's very clear which argument is which and why we're using it and so forth. So I commend that to you. And if you've written code already, then you probably want to review that because there are a lot of... There there are a number of subtleties to do with exactly... Well, which argument is which. The other thing which is... I have completely work... Reworked is the text about DKIM replay and how it might be detected because you can actually detect the... DKIM replay, basically, in DKIM two is is hard, but not impossible. And the role of the various features which stop Deacon... Which make Deacon replay hard is now carefully explained in that section about Deacon replay so you can see why you're checking what you're doing. It's also various people have... Of course, if if you're... Have lots and lots of mailboxes, then you understand all about Deacon replay, and you detect it probably today by seeing end copies. And... But there were confusion about people who said, but I only have one mailbox. How can I tell if it's a DKIM replay? And the short answer is you can't. However, what you can do is to pay attention to what has come in, and perhaps your local policy might be such that, if you were if you were suspicious about something, then you might like to do something about it. And in particular, this ties in with the reworking of the chain of custody checking, which there was an algorithm for before. However, that algorithm has now been sorted out because it was a little unclear what you did if suddenly the mail from started being null. And if mail from can become null in the middle of a chain, there's no various operational reasons why that might happen. So... And the other thing is the verifying n d equals, which we put in, which you may recall is saying, I'm not going to invent a... An invisible hop between these two. I promise you the next domain is... That's going to sign is this one, and you can check the the the thing there. But you can have actually chains of NDs. So you can have three NDs in a row and then only something with the mail from, And the algorithm as previously written didn't actually work when that happened, but it works now because it tells you what to do in every case. So I commend that to you and your Claude to review your code to make sure that your chain of custody checking is correct. That's really all I have to say about this. If people have any comments, then chip in now. Otherwise, we'll move on. It's kinda more a heads up than anything. Brian.
[00:37:43] Pete Resnick: Brian, you are not making any sounds. Brian is going to attempt again. Anybody else while Brian is working out his audio visual? There's Brian. Looks like MeetEcho was unmuted, but your local state was unmuted. Oh, and... Yeah. Alright. Well, you can move on, and Brian can get back to us when he's Okay.
[00:38:24] Richard Clayton: Sure. We can come back to this slide. Okay. Another slide, perhaps.
[00:38:34] Pete Resnick: Actually, if you wanna check, Brian's comment in the, chat room.
[00:38:40] Richard Clayton: How can you read? I'm not sure if it's He
[00:38:43] Pete Resnick: he says, trying here. I noticed that based on spec o seven, this would not be a relaxed domain match in the dkim signature. This surprised me as expected. Header.fromnoreply@example.com. Mfequalsreturn@bounce.example.com. Dkim two I equals one, d equals dkim dot example dot com. Basically, the from matches are one way downstream.
[00:39:12] Richard Clayton: The the... I believe the from is a relaxed match, as I recall. But you're gonna have to stick that on the list, and I can explain why. The the the actual things which are exact matches are things like the mail from in the in the Dkim two signature header and the... And also in the mail from... In the SMTP protocol have to be an exact match. But I don't believe that the authentic from has to be an exact match.
[00:39:52] Pete Resnick: That conversation can continue in the chat. And, Richard, you can move on to your next slide.
[00:39:58] Richard Clayton: Okay. Right. You may have seen some stuff on the mailing list because I certainly have on the topic of tagging with value syntax where I took it out because it was a large amount of explanation and we... And involve various features that we were not using. So I took it out. Hannah was very upset, so we put all sorts of text back in again so that, essentially, we had two headers which were, in fact, tagging with value or subset of tagging with value, but were separately specified. However, what I've forgotten was we used it in the Deakim in the Deakim keys as well where we can't change the syntax because we don't want to make existing key records invalid. We should keep on reading them, so we can't insist on the trailing semicolon. And then Bron was a bit sloppy when he stuck some tag equals value stuff into one of his drafts and ended up with a third version, which which Hannah was also upset about. And so I have just looked at this and thought this is just too much trouble. So I have put back tag equals value, which, of course, I could go and get out of out of my git repository. So I said put that back again. So that has been put back again. It's been tidied up very slightly, but I... Far as I believe is identical in terms of syntax to that which was in dkim one. But since it's in this document, then things can refer to this document so you don't... We don't need to point people at the one day becoming historic dkim-one document. You can point to this one instead. So ways draft... Keys draft can now point at this and doesn't have to repeat the stuff so we don't end up with the same text in multiple places. So that's just a tidying up and paying attention to people on the work group doing things. The document now has a section on international characters, which will not be a surprise to anybody. It basically says, don't worry. We've thought of this. And there is a security section which contains two useful pieces of advice. And secondly, there is some gratuitous advice that says that if you get something which is very complicated, you could spend a lot of time processing it and heating up and heating up the planet, and that might not be a good idea. Here's a generic RSC which discovers... Discusses denial of service attacks, and there's lots of other good advice. I'd be very happy to remove it because it's kind of motherhood and apple pie, and it doesn't tell anybody anything interesting. However, since we've had so many people on the list saying that we have to write down that people should be aware of people doing denial of service, the security section is the place to put it. If somebody would like to rewrite it completely, then I'd be very happy to let us Claude spell check it and stick it in. Okay. The from header being authentic, which we discussed at the last interim and on the list, has been added. I do not think that anybody's implementation will be affected one way or another because in the real world, when people are not doing bad things, from headers are authentic, so do not worry about that. We've now forbidden duplicate JSON keys, which was, to my mind, the only technical point to come out of a very long discussion... Very long discussion on the working group where people were upset by what we were doing, and we're also reading the wrong version of the draft. So they weren't actually sure what we're doing. But they did have one valid point, which is we've forgotten to say that duplicate JSON keys were not allowed. So it says that now. The other thing I have done is that you can, in fact, enhance the JSON. You cannot add new recipe steps. That's forbidden. And that seems right because if you have met an unknown recipe step, then it would be very unclear to you what that meant, so you'd have to fail things. But if people want to either add a completely different way of doing recipes, which is described at... As a different... They go under a different JSON key, or if something else needs to go into the how to undo things stuff, then you could have a new JSON key, write an RSC, and specify it, and previous things should not dongle. Now if people think we would never do that and that we should stop people adding unknown JSON keys, then it's a one line change to the JSON schema and perhaps a couple of lines of explanation drawing your attention to what the schema does to you. This has been done. I've added the the u step, which is to do with the fact that if you have a byte sequence... If you have an email which is in sort of just send date sort of world where it has not been encoded in any way, people have just sent the random contents of buffers or bytes and so forth, then you could actually have a sequence of bytes which cannot be expressed as a UTFK character because the UTF eight is like that. If you have one of these, then you would not... Never be able to write a recipe involving it. So we've added another sort of step, which is basically a raw encoding sort of a step called u. We discussed it on the list. It was gonna be b for binary or bytes. And my clause said to me, you've got a b already. It's a different level. Nobody will get confused, will they? I said, yes. They will. So we can talk with you. So that's something which if you're an implementer, you actually have to implement. It's one of the few new things in o seven. And the other thing is that you will now find the document is entirely consistent, and all of the Englishness has been removed, and it's US spelling and, appalling US grammar throughout.
[00:46:31] Pete Resnick: You do know the RFC editor is fine with British spellings and British grammar if you... If if you're consistent throughout. You can do
[00:46:39] Richard Clayton: I I I can turn it all into British grammar if you
[00:46:42] Todd Herr: can't ask me to do that. I I can do that, and I
[00:46:44] Richard Clayton: can put that whilst as well.
[00:46:54] Pete Resnick: Not seeing anybody yelp about this.
[00:46:59] Richard Clayton: Well, I'd... I've... To some extent, I don't... I wouldn't have thought so for these first ones. This is basically flagging up to people what I have done, in case anybody thinks it's, I was completely misguided and also as a sort of a heads up that perhaps if they're not gonna read the whole thing from one to the other, perhaps they ought to go and look at these bits.
[00:47:24] Pete Resnick: Alright. On you go then.
[00:47:27] Richard Clayton: Okay. Next one. I have removed do not explode, which the last interim said, I should do. And I have also removed do not modify because there was some discussion on the working group mailing list, and nobody said that they really wanted to keep it. And and a number of people said it doesn't work. The argument runs as follows, which is people are telling us that there is no way that they could possibly run their systems and honor these flags in the real world. So what would happen if they forwarded... If they didn't honor them, they then forwarded the message. Would it would it or would it not be a validly signed dkim2 message? And... Which the answer is probably no. It wouldn't be. And that would be dead inconvenient for everybody in sight. So what I suggested on the mailing list is that we take it out of the spec, which I have done, and that we then explore whether or not there is any cons... Any consensus around a noncontroversial different new header field. So instead of just having a yes, no flag or two yes, no flags, we have some sort of rather more flexible header field into which peep... Senders can put in. You can modify this, but only this far. And you might say, you can modify the subject line if all you're doing is sticking something at... Something in square brackets at the front. You can modify the you may modify the from if you want to munch it, because you're concerned about, DQ-one and, demark failures, and you... But you must never modify the body. So maybe we can identify some basic simple use cases for things, or you can modify it by adding up to two lines at the bottom provided they're in plain ASCII, and you're just advertising your mailing list or your college alumni football game or whatever. So there might be consensus here. If there was consensus, then this is something perhaps we should do, perhaps perhaps in mailman rather than here, but that would be the way forward. I am I am convinced by the arguments which have been made that having them as flags is not the right way to do it, so I've taken them out.
[00:50:08] Murray Kucherawy: Any comments, or shall I move to the next slide?
[00:50:12] Pete Resnick: Seems quiet. I I can cheer if you want someone to cheer.
[00:50:18] Murray Kucherawy: Very good. Onward, and someone can stop us if that was the... If there was feedback.
[00:50:23] Richard Clayton: Okay. There's a handful of things still to do. The IANA considerations section is missing. I think that we have to put in some IANA considerations, which says that we've invented two new headers and whether... We probably need to say whether or not they're trace fields, which probably will be able to help us say that very clearly. And, however, a very brief discussion on the mailing list. There is no appetite for writing many pages, setting up a registry for all of our tag fields, and so forth. If we don't do that, then it makes it a bit harder to modify Dkim two in the future because the sort of document you have to produce in order to modify it would be more complicated than what we just had when you were just adding something to a registry. Equally, I don't think in in our world, the concept of adding things to a registry and then expecting, that to make a difference to, how people processed your mail was in the least bit realistic. So I am perfectly happy to proceed with no registry for tags and no instructions to Ianna to make one. And if we want to retire in due course the d k m one registry for flags and so forth, that will be just fine as well. The second thing in the to dos, I'll go through all of them so people can comment all three together. Bronze authentication results document, look, I have referred to as I may use this if you want. I think the working group should adopt that, get it tidied up, and it should be pretty uncontroversial, apart from the fact that the way authentication results documents work is there's a chain of sort of 15 of them, which Murray has written all of them. So, then maybe we need... It needs to cover absolutely everything rather than just document what's been added. I have no opinion on that. And finally, Wei's document needs to leverage the tagging cause value stuff again to cut down its length. It needs the information it
[00:52:56] Pete Resnick: I just lost Richard. Did everybody else? No.
[00:52:59] Murray Kucherawy: He's showing as a detached client for me.
[00:53:02] Pete Resnick: Oh, okay. Well, hopefully, his his connection gets back quickly.
[00:53:08] Richard Clayton: Am I bad?
[00:53:09] Murray Kucherawy: There he
[00:53:09] Richard Clayton: is. Yep. You are. Sorry about that. Where where did I get to as far as you're concerned?
[00:53:14] Pete Resnick: You... The... Just two sentences, I'm guessing, if not one, we missed because we just left.
[00:53:22] Richard Clayton: Right. Okay. So I have mentioned Bronze authentication. Waze Dkim document needs to tag Eagles value sticking in it. The information which we have about post quantum needs to be fixed because it's a little bit more complicated than just saying post quantum exists. And we find suggestion for auth equals dkim two, I think, is extremely valuable. I think, as I said on the mailing list, that his other auth equals stuff is not valuable. Auth equals SPF. I'm not sure what anybody would ever do with that. But the auth equals Deacon two, super valuable, and we should deal with that. But that is not my document. That is that is Waze, so I bring that up. I do not believe, and this goes... Feeds into the working group last call stuff, apart from the issues we're about to discuss about signing keys and their algebra and the stuff which is on the still missing slide there, I am not aware of anything else which anybody is expecting to see in the spec document. And, therefore, once we finish this interim, once I push out o eight, I am very happy for last call.
[00:54:49] Pete Resnick: So go ahead, Emanuel, because my questions are strictly procedural.
[00:54:58] Emanuel Schorsch: Yeah. Something that I was wondering about, and this relates to both, ways auth equals Deacon two and, the... What you sent out about the authentic from. Don't really have any concerns about the authentic from, but I I do think that I would like to see a discussion around, additional language in the spec around, defining what it means to be an authentic from with body modification, because I think that that is a critical concept. I know that there are concerns that that John has around, requiring that. But I think defining that clearly is critical because, in my opinion, I think that needs to be, factored into the updates to the DMARC and the auth equals Deacon two to make it safe and for Deacon two to work in the same way that Deacon one works today, which is that if there is a p equals reject, should not modify it without modifying the front header. So I'd... I I think that's the one thing that I I think needs to be updated in a sec.
[00:56:05] Richard Clayton: What I would suggest to you is that that goes into the, replacement header field for... So instead of do not modify, that we put in something which says I do not expect the body to be modified on this message, or I expect limited modifications of the following kind.
[00:56:28] Emanuel Schorsch: Are you planning to send out that, proposal for that, like, permits modification?
[00:56:37] Richard Clayton: I I could probably have a go at a first draft of what that might look like. I think the real question is whether or not anybody thinks there's going to be any consensus around what it says. Saying no modification whatsoever as a header is obviously relatively... It's extreme. Right? So people... So you may find that the people who said that do not modify could not possibly work for them because they were legally obliged to modify messages when they forward them in the following way. They may say... But but the point... The point they were making was their modifications were extremely limited. They were just coming down to modi... Sort of sticking some text on the front of a subject line. They were limited to not very much else, basically.
[00:57:35] Emanuel Schorsch: So putting it aside the conversation around, like, kind of policy and what should be done, I... Maybe I'll send that to my... Because I think at the very least, it it needs, like, a different state. Like, just just to explain, like, in Deacon one right now, a Deacon one pass is relatively clear because you look at the Deacon one pass and you look at the front header. Okay. Deacon two, a pass is much more much more complex because it could mean multiple different things. And so I think that there needs to be a clearly different off state for it passed and the front header matches the most recent modifications versus it passed and there were modifications made, because I imagine that DMARC or other policy will need to build off of that, and I think it needs to be defined in spec so that people do not run around, with different interpretations of what that means.
[00:58:30] Richard Clayton: Okay. Well, I'll look at producing a draft and and see whether or not... We'll see whether or people hate it.
[00:58:38] Pete Resnick: I think that also goes back to, you know, Emanuel, if you have some suggested text for the spec that you think might be acceptable, that would probably be useful. I... I'm I'm, you know, in the old crusty people like John Camp who thinks that it would be exceedingly good if the the outcome of this is that mailing lists can avoid changing from and still make their small modifications and have the right thing happen. But, Wei, go ahead.
[00:59:17] Wei Chuang: Yeah. I guess going through the laundry list. Yeah. Plus one to adopting, you know, authentication results. I'm sure there's...
[00:59:29] Richard Clayton: I'm sure
[00:59:29] Wei Chuang: there's gonna be more discussions about that. But the question I have there, would it make sense to put the authentication result content into the main draft, or do you want to keep it as a separate document? Then the next thing around, the Deacon Keyes, space, basically, agreed we... There's going to be more work that we have to do for post quantum algorithms. And then, you know, there's... At some point, we need to have the discussion about, you know, this composite versus, and I don't... I guess we're not gonna do it here in this document, but I
[01:00:09] Richard Clayton: guess probably in the later discussion. Just just wait for the next slide.
[01:00:12] Wei Chuang: Oh, excellent. Okay. Great. Great. And then just, for the off equals, just pointing out, the reason why there is this notion of SPF DKIM is, you know, as mentioned or in the commentary and and the mailing list, I mean, is there because, you know, the default is SPF and DKIM. But if this tag is specified and it lacks SPF and DKIM, that's also important too. And then that's also supposed to help, say, at some point in the far future when, you know, DKIM two is well deployed, you know, there can be a way of describing, as a capability that, you know, this particular receiver or sender, you know, does not support, these other, legacy protocols. So just pointing that out. I mean, there's there's there's a reason for it. I mean, it's one of the things that I, I guess, for reasons, just didn't want to quite spell out as much in the document, but, but that's the reason why. Alright. And that's my comments.
[01:01:22] Pete Resnick: So... And, Wei, maybe stick around for a second, because my... So here's my procedural questions. I'm perfectly happy with the IANA considerations and procedurally whether Bronze document gets adopted or or how it gets adopted. Because it's referred to with a may, I'm not too worried about it. What is the the reference state for Wei's document in this document? Are they bidirectionally normative? Does this one Yes. Depend on Wei's, but Wei's does not depend on this one?
[01:01:59] Richard Clayton: No. They have to go out together.
[01:02:02] Pete Resnick: Well... And the the... I mean, there's no doubt in... As far as I remember, that this document, the spec is going to require Waze document. The question is, does Waze document depend on this document?
[01:02:18] Richard Clayton: It should do because it should pick up the tag equals value. I... Plus, it may not depend on it very much more, but we cannot ship them apart from each other.
[01:02:31] Pete Resnick: Because I thought part of the reason for keeping them separate was because there might be reference from old DKIM2 Wei's document or or something akin to that?
[01:02:45] Richard Clayton: The the the reason for doing it was really because I have to refer to the keys, because we want to change what... What's in the keys and the fact that various flags in there no longer have an effect. Some of them because they just said match with Deakim two concepts, and some of them because we do not wish... Nobody ever used those features, so we wish to deprecate them for... Basically, deprecate them for the good of the community so people don't think they have to add them. So we wanted to update the stuff. Didn't want to end up with writing all of this stuff into the Deakim two document, and we didn't want to end up with making people go and read the Dkim one document just for one section.
[01:03:35] Wei Chuang: Could we pull in the ABNF for the tag value from your document into dash keys slash d n s? And then that way, they we
[01:03:44] Pete Resnick: we That... That's exactly what I was wondering is Okay. If if you can make the the hard dependency, the normative dependency one directional, that, you know, it it loosens up some stuff procedurally. And maybe it doesn't matter, but I I the time check, Murray, we are at the halfway point here or a little past the halfway point.
[01:04:13] Richard Clayton: K. I think we can sort out the detail of that. The other thing I I really want to make sure everybody's clear in their mind, that auth equals Dikim two thing, which I... Which I'm saying is really useful, is nothing to do with dkim two at all. It's a way of improving your dkim one... Your... It's a way of improving your DMARC handler as to tell it whether or not a Dkim one pass is of any use whatsoever. So it's nothing to do with Dkim two. What's... Though it says auth equals Dkim two, what it's saying is auth really is Dkim two. So if you're not in the Dkim two bit of your code, say no.
[01:05:03] Pete Resnick: Like I said before, Emanuel, small enough group.
[01:05:11] Emanuel Schorsch: Yeah. So question around that. Because I I think that there's... I think the elephant in the room that we are, you know, punting on slash dancing around is what Pete was just saying. Right? That there's a camp of Pete, John, other people who want to be able to have mailing lists no longer modify the front headers. And it's a little bit unclear to me when that decision gets made. So from my understanding, as soon as auth equals Deacon two goes out, systems would start updating to treating a Deacon two pass as a demark pass. And that would be a fundamental change in behavior from what it is today. So I so I guess... Yeah. Richard, please
[01:05:53] Richard Clayton: correct that. What you're going to what you're going to do if you're a mailbox provider is you're gonna treat a Deakim2 pass as being a way of accepting mail, and you will probably spit out some some information for the report part of DMARC. But, otherwise, you're probably gonna take very little notice of DMARC whatsoever because it doesn't tell you anything you need to know. Because once you have a pass, demark doesn't tell you anything. Demark only tells you what to do with things
[01:06:28] Emanuel Schorsch: which are not passes. Right. But that's my point because that's a change. Right? Today, if a mailing list modifies the content, Deacon one would not be passing. And so that would then be in the domain of DMARC. In the Deacon two world, it would be Deacon two passing. And so that is a change of behavior, and I I... Like, it... At at what point would that be changed? Like, as soon as the Deacon two spec is out or only once, like, debugger spec is out?
[01:06:59] Richard Clayton: You're you're asking a question as what what do I think people's local policies will be? And that is not a question about a specification. That is a question about how mailbox providers will handle this mail. And I think what mailbox providers are going to do is they're going to look at who has modified the mail. They're gonna apply a reputation system to the person who has modified the mail.
[01:07:26] Emanuel Schorsch: This doesn't seem like a question of policy. Like, right now, we have a DMARC spec. It... You know, there's obviously... There's always local policy. But putting aside local policy, like, there is a there is a spec, and it's relatively clear of, like, well, if p equals none, then it doesn't matter. You shouldn't do anything. If p equals reject, you should do x. And it's clear that when that would apply, but it's not clear to me how that would apply in the Deakim two world, and at what point it would be updated.
[01:07:55] Richard Clayton: The only difference is that the that the the intermediary can change the mail, can tell you the... What it has done to change the mail, and arrange that it gets a Deakim2 pass.
[01:08:10] Emanuel Schorsch: But that's not a small difference. That... That's an enormous difference.
[01:08:13] Richard Clayton: That that that... That's a a big difference. Now the question is, are the modifications benign or not? Do you do you have, do you think the person making the modifications has a reputation, which means that their modifications are acceptable? And that is a question about local policy and content. It is not a... I... We have we have given a system which says that if you wish to modify a mail, provide you say what you've done, then you may do so. Now if you wish to layer onto... If you want to say, that has lost me some protection for for my my brand valuable mail, which must never be modified under any circumstances, then we need to talk about the the new header which says, you may not modify my mail. Right? But in order to have that conversation, we have to work with the peep... With the mailbox providers who are saying, we absolutely have to modify mail. Right? If you try and say we can't, we're gonna take no notice of you. Live with it.
[01:09:19] Emanuel Schorsch: Maybe I'm missing something, but I I am still confused, when things change. And because I'm confused, I feel like that would be enough reason where I would oppose, like, Deacon two being adopted. But maybe other people understand more clearly, like, at what point this would actually take into effect.
[01:09:39] Pete Resnick: Let me... No chair hat on. Just as someone watching this go by, let me give you what I think, operationally is gonna happen here. Remember that the other thing Dkim two gets you is the chain back to who actually made the change, right, which you didn't have in dkim one, which is part of the reason that people started saying p equals reject is you had no idea where these changes were coming from. Very quickly in dkim two, you can build a very sharp reputation system, which you couldn't do in dkim one because you didn't know who to blame. So I think the effects of not having this ability to say, I wanna reject it if anything changed the message and didn't change the from is not gonna be as important once Dkim two gets deployed. I think that's the outcome.
[01:10:46] Emanuel Schorsch: So I I understand that argument, and I I know we have a different opinion on this. But I think, like, the part that I feel like as table stakes is, like, I'm not understanding when that would actually take into effect. Like, I I don't think that should happen. I think that's a bad idea, but the basic question is, like, at what point would that change spec wise? Like, is it the moment that Deacon two gets adopted? My understanding was Deacon two, if it's adopted without the auth equals Deacon two, would just stand on an island. It's only once you update the D
[01:11:16] Richard Clayton: Mark's No. No. No. No. No. No. You completely misunderstood. It's nothing... The auth equals Dkim two is a protection against people stripping Dkim two headers, leaving in Dkim one's headers, and then leveraging the bad things that you can do in Dkim one. And what that says is that I... You... What you... If you write auth equals dkim two, what you're saying is I sign with dkim two. If you can't see a dkim two validly signed message, then reject it. That's all that's saying. It's a it's a stopping people doing a fallback to the previous protocol attack. Got it. It has nothing to do with modification of mail and whether or not you trust the people who make modifications or whether or not the modifications are benign. It is a statement about, I am a Deakim two user. So if you see something which is not Deakim two signed, it ain't from me.
[01:12:12] Emanuel Schorsch: Apologies. I think I mixed this up with the DMARC proposal to update what is considered valid for off state for DMARC. So never mind. But I guess I think... I... Just because I think it's still relevant, like, what is the answer to my question? Like, DMARC today doesn't include Deacon two. Right? So Correct. Even if this... The Deacon two spec is adopted, DMARC policy would still say, if it's failing Deacon one, then it's not it's not a a DMARC pass. Is that... Am I understanding that right?
[01:12:49] Richard Clayton: Yeah. You're correct.
[01:12:50] Emanuel Schorsch: Okay. Thanks.
[01:12:52] Richard Clayton: Right. But but but what I think my day job will do is it will say you got a DKIM two pass. We are not going to throw it at the DMAR handler because we're not... Because if you had the d kim-one pass, effective, we would not throw it at the d mark handler apart from the fact to make a a statistics note for our report at the end of the day. Okay. Let us move on, and then we can have fun because we'll get to the controversial bit. Another slide, perhaps. Okay. Now the last interim selected... I spelled it wrong. M l d s a 44 with e d two five five one nine r s a five twelve, which is a hybrid algorithm of a lattice algorithm with a elliptic curve algorithm. And we said that is what we would put down in the spec as a a placeholder for what we finally decided at the point of which we shipped the document. This has now been added by me and by Wei. Wei, I'm not gonna blame Wei at all here because he wrote down what I told him, wrote down... Write down, and this has been added somewhat incompetently in that I have not put in the information, which it is clear from that fine lamps document there, is required in order to be able to know what you're meant to do. And it also needs a handful of very small print decisions about what we're going to do about stopping cost protocol attacks and so forth, whether or not we're gonna do anything about that. Don't wanna go into that bit of it. But, basically, what is there is not sufficient to implement against. Somebody has implemented it, and what they did is they guessed and I think correctly as to what we meant. However, there's a lot of other issues about the spec for crypto keys, which pairs people on the mailing list keep spotting. My claw tells me there's 11 major inconsistencies at the moment and numerous other holes and so forth. I did not attempt to fix them for o seven because I want to go back and revisit an old decision of ours, and, trying to deal with the consequences of that decision is what has caused a certain amount of the inconsistency. Because in various places, the spec tries to fix things up in order to deal with some foolish... The foolish results of what we decided. And in other places, it doesn't, and that creates things which say one thing in one one place and one thing in another. Next slide. Okay. To set the scene, dkim2 has has a key aim from day one that we wanted algorithmic dexterity. And the working group decided in their wisdom at, in fact, one of the online meetings that having one valid signature was enough, which we will describe for... Has an or algorithm. Basically, one okay or another okay or another okay, however many signatures you got. If one of them passes, that's just fine. With the concerns which drove that decision, I think, are, first of all, that verifiers would not know about all algorithms. And therefore, if you had multiple algorithms and a verifier didn't understand one of them, then it would have to say no. That's a failure. And that would be enough to cause the thing not to get delivered. And people didn't like the idea of stuff which was apparently validly signed, had a valid signature on it not being delivered. And the other thing is that people were concerned that implementations of these fancy new algorithms might be buggy, and they're... And they... So they were... They wanted one pass to be okay. Now the alternative to this is that all signatures must pass. So... And one of the... So the first observation is that this... The the algorithms, both hashes and and the post quantum, which we've selected, are in practice universally available. Now that's not true of the hybrid which we chose. Now, actually, building the hybrid out of raw components is not super complicated. This is a little bit fiddly, but talk to Claude, and he will do it for you. And that and that, again, I want to stress is the story these days. If he looks fiddly, ask Claude, and it won't be fiddly. I provided it's well specified, and how to do the hybrid is extremely well specified in that labs document, then it's straightforward to do it. If we did do hands, then we don't need to use a post quantum hybrid because people who want the hybrid property will sign with post quantum and with elliptic curve or RSA or whatever they wish to do. So hybrid in that sort of sense is free and just turns up, and you can do it. And the other observation is that I really am not convinced by this while the world is full of buggy and and interim implementations. They may be slow, slower than they should be. They may have timing as... Attacks, which are possible on them because writing a crypto algorithm which is susceptible, which is immune to timing attacks is super complicated, and people still find timing attacks on all sorts of classical stuff, which we think has been settled for twenty years or so. But actual bugs in the code, so it just produces the wrong set of bits. There's piles of test suites and so forth. There's absolutely no excuse for deploying it. Next slide, please. So what I've tried to identify is where these arguments come from. And one of the arguments is about past history. And past history is pretty clear, is that we added elliptic curve, that's e d two five five one nine, Edwards curve, and basically, nobody bothered with it. And why did nobody bother with it? First of all, people froze their code base years and years earlier, and we didn't have Claude at the point of which that came out. The... What elliptic curve mainly gives you is shorter signatures, and that was no particular reason why anybody would want to change to them. Who cares that they're shorter? It's just pints in a header field. And the all semantics of Deakim-one meant it didn't actually matter. Deakim-one has all semantics. It only has one signature at a time, but the way in which everybody implements it means that if you want to sign with RSA and with elliptic curve, you put in two Deakim one signatures, then you basically get all semantics, and that just works for it. Yet... But for Deakim two, this is going to be different. First of all, one of the handful of... I think there's two musts on the whole of the... On the verifier. One of it... One of the musts is that you have to implement all the algorithms we mentioned. So r c 10, whatever it's gonna be, he's going to say, these are the algorithms, and you must do them. And I expect to see people generating torture test emails in order to send them to to your system and then point and laugh when you, when you fail to validate them properly because, you can't be bothered to implement Deakim two properly. And you should implement Deakim two properly because you will say to Claude, here's the spec implemented, and Claude will just do all the algorithms automatically because he will know no better. Next slide. The second argument is about what future history is gonna be. And the main worry is that the algorithm which we've selected, which I've spelled correctly on the slide, will turn out to be rubbish. And so we're gonna have to change to a different post quantum thing, and that won't need to work for a while because people will not have implemented it for a while. But is that actually going to be a long while? You are just gonna go along and say, Claude, fix my library, and Claude will understand the new algorithm which has been selected, and it will all just work. So there is not going to be a long period where people have not upgraded because, if people insist on the new algorithm and you have to use it, then you're gonna have to use it, and you're just gonna say fix the code, and it will get fixed. You can still sign with just RSA or Elliptic Curve if you want to, if they're still considered safe at that point. So you can just fall back to one of the other algorithms rather than, this, thing we chose and turns out to be rubbish. Assuming it does, there's no guarantee one way or the other. The other thing to say about using and semantics, which I I am very keen on, is that the the the delivery status notifications will tell you immediately which systems don't understand your something better, at which point you can do... You can adapt what you send to them or bring them up and point and laugh or whatever you wish to do. Whereas if with all semantics, you have... You can never never know for sure when you can change over because if you're signing with several several algorithms, your stuff will get accepted. I think I have one more slide. Did I have one more slide? Yes. Okay. So the case that for hand, which I wish to commend to everybody, is that if we do hand semantics, then we don't need to have the hybrid thing, which people are concerned that they're have to write the hybrid bit... Hybridness themselves. I don't think that's a real concern, but they're they're worried about it. We can just use post quantum, and that's available pretty much. That MLDSA 44 is available everywhere. The... As I said, my claw has 11 major issues and so forth. Looking at that list, it is going to be easier to explain and semantics and keep the documents simple. And I would argue it's better engineering and so forth. And, yes, it is fragile if we change the post quantum algorithm down the line, but I think fragile is the right thing for security mechanisms. Security mechanisms should be failing and failing hard. If they don't work, they should not be hiding errors, and letting you think that you have some security you don't. And I expect a discussion on this.
[01:24:11] Murray Kucherawy: Brian, take it away.
[01:24:16] Bron Gondwana: So by and here, you mean that you have to pass all the algorithms that you have encoded into the header. Right?
[01:24:25] Richard Clayton: Yes. If if if there's more than one signature, they must all pass.
[01:24:29] Bron Gondwana: What stops the bad guys taking one of the signatures out?
[01:24:34] Richard Clayton: The fact that the... Nothing. We could put... No. The... We could put account signatures so they can't do that from the syntax.
[01:24:50] Bron Gondwana: That seems kind
[01:24:51] Richard Clayton: of crazy. We can we can do that. That's easy.
[01:24:54] Bron Gondwana: Yeah. I don't I don't think that wins there. Mean, it it seems silly
[01:25:02] Richard Clayton: to me.... Comma, but alright. We we can fix that so they can't take one out. Okay. That... That's trivial to
[01:25:06] Bron Gondwana: me. Yep.
[01:25:15] Wei Chuang: Yeah. So I like the idea of not doing a hybrid because, you know, I've I've posted down the list. You know, I saw that the libraries don't natively support that, and I am anxious about trying to... Even as something... Supposedly as simple as implementing this particular form of hybrid, worried about that. And I guess maybe some of that reason is because, of course, I was writing up the errata, for, you know, RSA, which in theory was something done a long time ago. And, basically, I guess, the natural evolution kind of smoothed it over, but there wasn't errata basically around, you know, just the fundamentals, right, which is hard to say. And I think, you know, there's a little bit of warning around that lack of adoption for, you know, Edwards two five five one nine. I mean, I think while we can toss things into Claude, there's still risk, and I'm just pointing that out. Hence, I think, you know, I... And as mentioned on the list, we need some way of upgrading. So I think having some ability to do an or for the introduction of some new algorithm in the future is a good idea. It doesn't have to be the default, but there needs to be a way of expressing that when I'm introducing a new algorithm someday, I'm sure it'll be, like, some newfangled post quantum algorithm that, while doing that and because the community is very nervous about deliverability, that there is a path for that. And then so having some sort of flag, that allows for the ability to express an or condition, I think, would be a good idea.
[01:27:19] Richard Clayton: I suppose we could produce a... One of these or that. If we're gonna have changes in taxes, Bron points out, in order to make sure that people can't strip stuff, we could probably manage to put that in. That might make people happier about the future history side of things.
[01:27:40] Murray Kucherawy: Allen, go ahead.
[01:27:44] Allen Robinson: I mean, there... There's a third option, which I think we discussed at at one of the early meetings, which is all that you understand. And... Well, the problem with saying all is that if I... If a new algorithm is introduced, we now have to wait for all the verifiers or enough of the verifiers globally to have implemented such an algorithm before anybody can send mail. And that doesn't feel great.
[01:28:21] Richard Clayton: Well, if if it turns out that m m... MLDSA 44 is broken, then many things will feel not feel great. I'm fixing your mail system. It's going to be one of the things on a long list.
[01:28:36] Allen Robinson: So I... I'm not... Maybe I'm not that pessimistic about MLTSA actually being broken. I I think the the more likely, hopefully, scenario is that we find an algorithm which is quantum safe and also not obscenely expensive like the current one is. And then we introduce it. And we shouldn't penalize people for adopting, like, adding their signatures with this new algorithm. Right? Like, it it sort of turns into a bit of a flag day where you you have to, like, coordinate with, I don't know, the top 100 peers or something to to figure out, oh, yeah. Everybody that I care about is... Has implemented verification for this algorithm, so now I can send it. I'm just... I I don't feel like we're getting a whole lot out of out of the statement that you have to reject mess... Or you have to treat as not Deacon two authentic messages that have a signature that you simply don't understand.
[01:29:48] Richard Clayton: Well, at some point, you are gonna have to drop the ones which are not safe anymore or which you... Or switch to only using the one which has the new property.
[01:29:58] Allen Robinson: Yes. But but, like, at some point is not at a point in time, we all decide.
[01:30:03] Richard Clayton: Well, is it is it still gonna be a point. It's going, you know, it's gonna be a Yahoo goal next February date or something. So there's gonna be a flag... If we change this, there's gonna be a flag day. Believe me. But it doesn't have to be. It may not look like one, but it will be. Because people... Because at some point, you're just gonna have to say, if you can't cope with this, then then tough you can't deliver mail anymore.
[01:30:33] Allen Robinson: But but that's that's the verifier saying we're only going to accept this. Right? So, like, presumably, these verifiers have rolled out support for supporting it, and they're telling signers now you can go do it or must go
[01:30:48] Richard Clayton: do it. No. The deliverability is the fact that the sender wants to only put on them the super newfangled one. Right? And They they said that that their deliverability will suffer if they do that.
[01:31:04] Allen Robinson: Well, yeah. The set... The sender wants to know that adding the signature won't impair deliverability, and it will impair deliverability toward any site that doesn't support the algorithm. Yep. Like, it's... The the previous industry statements where the verifier says you must use... You know, you must do this, did not impair deliverability to other systems. They they merely were a minimum bar to deliver to this specific system.
[01:31:35] Richard Clayton: Yes. Where
[01:31:36] Allen Robinson: the... This statement of if you don't understand the algorithm, it gets rejected or it gets... It... It's not treated as Deacon two authentic. It it does very much mean that policy at one thing saying you must use this algorithm at a minimum, you know, now it affects deliverability in other places. Because I could, if I decide I wanna do MLDSA plus some new thing, and I do both of them, like, everything's fine.
[01:32:10] Richard Clayton: Right? As long as both of
[01:32:11] Allen Robinson: them are passing, everything's fine. If you only understand one, things are great. And if you understand both, things are still great.
[01:32:24] Richard Clayton: Well, I we could do a syntax which says... Which has the ability to put one or in the middle of a set of signatures. So you can have nought or more signatures to the left of an... Or one or more signatures left of an or, one or more signatures to the right of an OR, and overall counter signatures, and the thing will do the semantics. It would not be a vast amount of code to implement at either end. Then then we have something which is flexible, and people can shoot themselves in the foot.
[01:32:58] Allen Robinson: And I guess it'll depend on what that's... How how bad that syntax looks, whether it's actually worth the the
[01:33:05] Richard Clayton: Give... Given how big some of these signatures are, you... You'll struggle to find the syntax.
[01:33:16] Allen Robinson: Sure. I mean, I I guess I would need to see it. It's it's... Yeah. Thanks. It's still... It's hard to comment on something that I haven't seen.
[01:33:30] Richard Clayton: I can write a vertical bar instead of a comma.
[01:33:35] Allen Robinson: Yeah. We're we're running out of separator characters. Right? Yep. Well, I guess I guess within the context of a single value, it's not too bad. But, yeah, we need to we need to have a strategy for how to roll this out because I don't
[01:33:50] Bron Gondwana: think, like,
[01:33:52] Allen Robinson: every signature must pass is gonna gonna scale. I think that's it for me on this on this specific topic. I don't care about hybrid, I guess, is is my other thing I should say.
[01:34:15] Richard Clayton: I do not want Dan shouting at me.
[01:34:19] Murray Kucherawy: Anyone else for this slide or any of the other slides that Richard presented? Pete
[01:34:25] Pete Resnick: and
[01:34:25] Murray Kucherawy: I were talking in the chat, and I think I don't hear any action items specific to the group other than please review and comment on these changes. This... We want to make progress toward working group last call in the near future. So... But we need feedback to confirm that this is now the consensus that we're here. We're on.
[01:34:45] Bron Gondwana: I just wanted to pop in to say that I don't want Dan shouting at me is not a good protocol design. I I I understand it, but also that is anti how the IATF is supposed to work, and we shouldn't use that as a consideration.
[01:35:01] Pete Resnick: And I I will say that that that if there is concern about Dan shouting, your chairs and ADs are here to be shouted at, not you.
[01:35:14] Richard Clayton: Right. But the other thing is I I kind of think he has a point. He puts it across in an interesting manner, but I think he has a point. And I think hybrid is the conservative and right thing to do if you're going to use post quantum, and that and that by using hand, then you can do it in a conservative way without ending up with quite as much... Having to read quite as many paragraphs of a 230 page, whatever it is, LAMP's document as you might have done otherwise.
[01:35:53] Pete Resnick: Then would be much easier to deal with if you were wrong more of the time. Alright. Well, I think we will clearly look out for this on the list, and we'll flag this in the, in the minutes. But, this discussion will need to settle in on the list. Alright, Bron. There are twenty four minutes left in the hour. Do you wanna give a go at your implementation discussion?
[01:36:33] Richard Clayton: Sure.
[01:36:33] Murray Kucherawy: I think I think Wei's item was second on the agenda, but I don't I don't mind switching them.
[01:36:40] Pete Resnick: Oh, did Wei have an item? I thought Wei was just up with Richard on the the PQ discussion if needed.
[01:36:47] Murray Kucherawy: The agenda posted says post Quantum discussion, Richard and Wei, and then implementation notes, Bron. If if there's nothing to do in the post Quantum, we can move on past it.
[01:36:55] Pete Resnick: Did you have anything else, Wei?
[01:36:57] Wei Chuang: No. I I think that discussion we just had on post Quantum covered all the points. That I think said.
[01:37:05] Murray Kucherawy: Implementation notes coming right up. Alright.
[01:37:10] Bron Gondwana: There we go. Thank you. Interop interim implementation, something like that. Do I have slide control here?
[01:37:22] Murray Kucherawy: I have a request for slide control. It wouldn't let me pass it to Richard for some reason, but... Whatever.
[01:37:28] Bron Gondwana: I I can just You do
[01:37:29] Murray Kucherawy: got it.
[01:37:30] Bron Gondwana: Okay. Yep. Sweet. Do I got it?
[01:37:42] Pete Resnick: You got it.
[01:37:43] Bron Gondwana: There you go. Sweet. Finally. Okay. Bounce around a little bit. As I was saying, interim... Interrupt implementation. I've done a bunch of stuff. This is just my implementation. There are other implementations out there. I have the Pearl mail dkim module, which is at 0.27 now. Change is happening pretty fast because I keep testing different things and then running into issues. And, of course, Cloud makes it very easy to just create a new version for everything. There's also a gerling, python, c, and JavaScript implementations, particularly in browser validating uses JavaScript so you can validate Dkim2 using Cloudflare's HTTP DNS without needing anything but your browser. I also have implementations inside Mailman and Simpler. Though, as you'll see later in here, I've also managed to make Mailman work just with stock Mailman. And you can... With a couple of configuration options, you can run that just fine. And, of course, Fastmail is running Deakin two. It's back o seven now for Fastmail and TobyBox is still on spec o six for the next hour or so until I deploy the change to that. But that's all up and running and and working against all the other stuff. One thing I ran into was efficient validation of message instances. I figured that you could actually make this a whole lot more efficient by running all the hashings at the same time and this can be done purely with streaming. So it reads all the headers into memory first and sorts out for every single message instance what the exact body copy ranges from the original body will be and then, you know, which lines go into your final hash value and you can just feed all the lines through in a single stream and you know which lines you have to look at. Alright. Next slide here is this. And then for Deakim two signature validation, you can also immediately, you know, that which DNS records you're gonna need. You can kick off the request for them as you've finished passing just the header section of the message and then wait for them to come back in. And at the end, you then check them. So I've started with eight. I send eight requests off at once. If there's any more than that, I'll wait just so that I don't deny all the service attack my DNS server. And then can calculate... Can do all the message instance validation while you're waiting for those DNS responses to come back because you don't need them to check the hashes. So I always check the hashes first and then the signatures only follow message instances pan out. One thing I said here was, particularly with those big keys, if we included the public key in the message, then all you would have to do is check that the key in the DNS actually matches the key that... Like, the hash of the key that's in the body or in the head as the message, and you could do that entirely. For Mailman integration, I've got one that patches it just by adding the... Basically wraps it with a... An empty... A multipart mixture, so the single part, and that forces Mailman to use that as its container rather than doing the rewriting it would do otherwise. So that has almost no change at all to mailman. You just say rewrite from if you wanted to always rewrite from and apart from that, tell it not to not to fuss around too much and it's all very clean. And so I've got that working now. There's a test list on dkim2.com that you can send to. You can add yourself to and that will make no no patches. It doesn't turn on the dkim two support that's enabled in Mailman. But, yeah, that just works cleanly. So that's all usable. Here's some of the things I ran into while I was implementing. Content length, recent BCC and BCC are stripped by post fix. So not that you tend to see them coming across the wire, but Claude said this is a problem. You want to make sure that you don't do that. So I've got the very first Milter running very early and it turns off all those rewrites. And so that milter sees it, stamps a message instance on at that point and tracks the copy of the message. Both Fastmail and Postfix... Yeah. Fastmail and TopicBox had our own non x prefix fields that we were stripping on egress. And so there's basically two solutions to that. One is to rename them and the other is to have your Dkim2 validator and signature calculation skip those fields explicitly and then, you know, that you're stripping them, but then you have to absolutely make sure they don't leak out because if you do, it'll break the signature the other way. Obviously, post fixes eight bit to seven bit conversion is going to make... Break things. And so disable MIME output conversion, that's gonna be an issue generally, Pete. I I don't know. I don't think I've ever seen it come over the wire. Obviously, you need to split into parallel recipients at the point that you're gonna start adding Deakim two signatures. But you can still... If you're building software that you need efficiency on, you can calculate the message instance once cause that doesn't change between the copies. And then it's just a Dkim two signature that needs to be redone for each of the other messages. And depending how cradle you want to make things more efficient, you could also hash all the other headers and just have the final d k m two signature because it's always the last one. It's the only thing you'd need to change each time. But generally, you don't have that many recipients anyway. For oh, so there... Yeah. For... You need to modify... Minimize what you change in terms of being able to undo. So I talked a bit more about that in the later slides and send mail PML to Perl module had a bug, but that's now fixed upstream. So that problem's gone away. Minimizing the modifications, basically, what I came up with for this was that it's gonna be encoded in some way by 64 or quoted principle potentially. And then there's HTML text. And finally, the DOM is what you want to actually be changing. So what you wanna do is convert it through to the DOM, make you change to the DOM, but then stream the original file again and replay until you hit a point where there's a diff in your DOM. And right up until that point, you're replaying exactly the same items all the way through and you keep the exact encoding. So same line length, same... If it's quite a printable, same characters being quoted or not quoted. And so once you get through to that eventual end point, then you you only need to make the change there. Yes. It does. Doesn't it? The other thing is that you can also be clever about how you restart afterwards. It's a change right in the middle. You might need to white space pad a little bit so that your base 64 realigns and then wrap your line at the same point, and then you can keep playing. Basically, you want to make it look as similar as possible to the original message so that all the lines that contain the same content are the same. And then it's just those intermediate lines. And topic box does that. So it streams streams through, replays the encoding, and even when it's stripping a signature out of an old message and putting a different signature in there, it makes for quite a small recipe line. My code at the moment will do up to 100 lines that need to be copied into the recipe. And if more than a 100 lines needs to be put into the recipe, says, this is too hard. I throw my hands up. I'm just gonna say I'm not able to describe this change. And I figured that was a a reasonable way to keep the message instance not too huge, but that's just what my implementations do at the moment. And, yeah, as has been discussed a few times here, it is incredibly easy to write software with today's tools. The main thing is having clear descriptions of of what's important. And so what I put on these slides, plan to write up as a more detailed... Here's the instructions to give to your junior programmer slash software development tool slash team on the other side of the world and tell them what to what to implement to make this reliable and make it efficient. I think o seven is is pretty much ready for widespread testing. I ran into a couple of tiny nits which I sent to Richard, but they were really minimal nits. It looks really good, so I'd love to have more implementations to test against. I'm gonna be speaking about Deakim2 in Washington DC on the November 3 and then in Tokyo on the November 6. So I've got lots of lots of travel and lots of talking coming up. I'd love to have more implementations to test against. And does anyone have any questions on this?
[01:47:21] Pete Resnick: Nobody? I mean, all this makes me very happy. So... Cool. I'm good.
[01:47:28] Bron Gondwana: Yeah. It's it's pretty nice. Fastmail is completely... Every Fastmail customer's email now goes out to dkim two signed. Every Fastmail received email gets dkim two checked and gets a very slight bump to its spam score if it has Dkim two on it, mainly because that slight bump then puts an encoded thing in their spam hits so you can test against it. And you can see this came in with Dkim two signature easily. And, of course, the authentication results works like my doc says it does.
[01:48:02] Murray Kucherawy: Richard, go ahead.
[01:48:04] Richard Clayton: I wanted to remind everybody that when we started, we said that we were really interested in running code rather than fancy designs, and we have running code. We have a fancy design as well, but it it is implementable. And besides Bron, who's done quite a lot of different implementations, there are other people speaking up and saying that they they have running code, and it is and it is there. So that is that is a good sign, and I think something that... Down as the chairs will be pointing out as they send it off through processes and so forth, which is here it is, and it and it works.
[01:48:48] Pete Resnick: I was gonna mention... I mean, I think it will make life rather pleasant for the chairs if you two are able to scrape this together into an implementation status section, you know, with the, you know, to be removed by RFC editor. But, you know, it would be great to go into last call with a description of people who are actually implementing it and what the outcome has been.
[01:49:15] Bron Gondwana: Yeah. I know Mara has done it for StellWard as well. So think we have quite a few implementations out there. And Brian, awesome.
[01:49:28] Pete Resnick: Cool. Makes me happy.
[01:49:32] Bron Gondwana: Yeah. Alright. It seems it seems quite implementable and and usable in its current state.
[01:49:43] Pete Resnick: Well done. And, Richard, I take it that's just an old hands that's sticking up there. Alright. Well, we are ten minutes to go and down to all other business. Anybody got anything that they need to discuss at the moment? Go ahead, Wei. Yeah.
[01:50:08] Wei Chuang: So, so I sent out, an update to the, what I call the sender policy document, but it's like the d q m two DMARC document, really about how to fetch the DMARC policy. One of the things I wanted to do was send it... Make mention of it out on the DMARC working group mailing list. And since I haven't really gotten any new comments on that document, I was thinking of just posting it over there to get more comments. And before I do that, I just wanted to see if anyone has strong opinions before I do that.
[01:50:51] Murray Kucherawy: No. I I think that that working group is a little bit on the dormant side now, so I don't know what sort of responses you're going to get. But I think there's no harm in trying it.
[01:51:01] Wei Chuang: Sounds good to me. Richard?
[01:51:08] Richard Clayton: I I did reply on the list to you. So you I'll take a look. Said. You you may or may not wish to accept what I said back to you.
[01:51:19] Wei Chuang: I probably have missed it. Can you summarize?
[01:51:24] Richard Clayton: Well well, basically, I said a couple of sections were you... There was a section which was overtaken by events by spec o seven. There was a section which you said was a a... Which you indicated was a change to the DQ-two and I think it's a change to the BCP you're asking for. And thirdly, it was the... Your remarks about auth, which were in there, which, as I say, I think I'm mistaken.
[01:51:58] Wei Chuang: Okay. Fine. Maybe we should iterate on that before I send... Cross post it because I I mean, it's not too far removed from what we've just discussed earlier. I mean, basically, basically, the auth... You know, there's the DQ-dkim2 part, but there is also a very, important intent to also signify basically the... In some point in the future, a deprecation of other legacy algorithms. And that was the only intent. And then, otherwise, you know, the lack of an auth just indicates that, you know, a party most likely supports SPF and DKIM.
[01:52:38] Richard Clayton: You can only tell if they support SPF by the way I'm looking at that SPF record and seeing what it says. Right. The... And at the moment, the the good security advice, which is to to... If you are if you are signing with DKIM, DKIM one or DKIM two, then for god's sake, set your SPF policy to say that it must not count towards DMARC, and here's how to do it. Right? At the moment, a awful lot of people are signing with DKim, and they have a SPF policy which says anything from Google Cloud is just fine. And that is a serious mistake, and the bad guys find those domains and send spam at scale.
[01:53:31] Wei Chuang: I mean, there's a sort of current state of authentication practices today in a far distant future. This is just meant to help clarify in that future state, you know, who all is trying to do what. And I think there's, you know, that way parties, you know, sending traffic can have some sense or, for that matter, receiving traffic can have some sense of what sort of authentication stance that they meant to send traffic out as. So, I mean I mean, if the concern is around, you know, non... The the SPF and the DTM parts of the auth tag, I, you know, I believe there's value in being able to, like, have parties be able to declare which of these things they support.
[01:54:30] Richard Clayton: Well, I see value in declaring that you support Deacon two. I see because what you're saying... But only in the sense of you're saying, I not only support it, but I always use it. Therefore, if you see something without it, then draw a conclusion. And I'm not sure whether or not... That's a... Then that is a very valuable flag and to to prevent people stripping things. And I... But I don't think that the equivalent statement in the Ezekim one world is of value to people. And in the SPF world, then I think calling it authentication is stretching
[01:55:13] Wei Chuang: Right. Right.
[01:55:14] Richard Clayton: Stretching the dictionary a bit.
[01:55:16] Wei Chuang: Right. I I... Basically, it it helps at some point, say, to the world when works in some sense done, right, I I think with these other mechanisms. I think there's a a value in... Particularly for things like Deacon where it's very hard to know who all is still using it. I mean, you can look at the the messages you get, but then you you don't have complete certainty because, you know, maybe someone's stripping it. And SPF similarly. Right? I mean, unless you're directly talking to that party, you don't know. But this allows for some way of declaring that support. And at some point, you know, if we have a sense that people don't support anymore, I think that can be a very valuable signal in the future. Alright. Yeah. Time track. Anyways, I can put this out on the list, and and I guess we... I can continue the discussion, basically, I'm saying, on the list. And I will just wait till that, I guess, resolved and then... Before trying to post out to the DMARC list. That's all I was trying to check for.
[01:56:31] Pete Resnick: Yeah. I I think, I'd like to, you know, at least have other than you and Richard, going back and forth about this and come to a conclusion that would make me happier. So, yeah, let's get it out on the list and see what happens.
[01:56:47] Bron Gondwana: Okay.
[01:56:49] Pete Resnick: Alright. Anything else? Sounds like we are pretty much done for the day. I owe minutes for the last interim. Murray will owe minutes for this interim. We will try and collectively get our acts together. Murray's act is more together than mine, but, you know, that's the way these things go sometimes. And
[01:57:16] Murray Kucherawy: agenda items for 01/27 since it's less than a month away now are are welcome first. I'm open to suggestions of what we'd like... What what what do we still need to talk about after this meeting? Send them on to the list or or to me. That's all I got.
[01:57:36] Pete Resnick: That's it. Alright. Well, thank you all. That was useful, and productive. And we will see you on the list and hopefully see all of you either virtually or in person in San Francisco. Talk to you soon.