Session Date/Time: 23 Sep 2026 20:00
[00:00:06] Pete Resnick: Murray, do you wanna be the slide driver, or shall I? Murray is now completely in the room. Would you like to drive slides, or shall I?
[00:00:20] Murray Kucherawy: Good morning. Alright. Let me find them. I got it.
[00:00:24] Pete Resnick: It's well past afternoon even for you.
[00:00:28] Murray Kucherawy: Like I like to say, it's morning where I would rather be. K. The slide should be visible.
[00:00:36] Pete Resnick: Yep. You're good to go.
[00:00:43] Murray Kucherawy: Okay. Let me I'm just finishing getting my client set up. One more moment, please. Okay. Welcome to IETF one twenty six point one. This is the DKIM virtual interim, September 23. But how is that an audio of Bron, are things okay? Sound is a 100% my right channel clear, though. Okay. Is anybody else lopsided like Bron is?
[00:01:14] Pete Resnick: It it is my audio also coming in on just one side, Bron? Well, then I I think it is a Bron end of the world problem.
[00:01:26] Murray Kucherawy: I I will lean slightly to the right. So running through the standard set of slides, please note well. The note well, this slide highlights a bunch of other RFCs that define procedure and formal procedure, but it's also, I think, some is it doesn't mention I thought I mentioned 27 seventy two eighty two. Never mind. Policies and procedures of the IETf and most particularly your obligations around conduct and rights and contributions. If you are not familiar with these, please let me know or please review these. You are expected to know them if you're gonna participate in the working group. Meeting tips. Please make sure you sign in via the data tracker. I imagine most of you are if you're in here, have already done this. Please use the Meet Echo client. That's more of an on-site thing, I think. Definitely join the mic queue rather than speaking, and please do participate in shows of hands. Please don't send video unless you are on the mic. Remote participants, right, same sort of thing. And use of a headset is seems to work very well with this client. Agenda. Our our this is actually, that's only appropriate for in person meetings. I should remove that that one. Others other pieces of information and links that are helpful for meetings and participation in meetings and issue trackers. If you have problems with the software, please report them to the tools team. You'll you can see how at that bottom link. Do we have did you secure before I join a chat relay volunteer or minute takers or any of these things?
[00:03:18] Pete Resnick: I did not. We are being recorded, which makes that rather handy. But
[00:03:25] Murray Kucherawy: Easily. Yes. Yeah.
[00:03:26] Pete Resnick: I will put myself into the note taking tool. You will note that there is a an icon center of your screen with a little pencil and pad. If you would others join us in the note taking tool and at least scribble down what you notice. And if you say something and one of us scribbles down something incorrect, please do help out.
[00:03:49] Murray Kucherawy: In particular, action items, things we have agreed that we're going to do. That's really the critical thing to record and make sure that that'll help us make sure that they are highlighted in the minutes. Next slide is the agenda. These are the items that were brought up that people would like to get time for. We didn't actually attach an amount of time to each. We have a two hour meeting today. We'll just get through as many of them as we can rather than chopping stuff off the bottom because we couldn't quite tell how long any of them would take. Any extra material can be go can go into, let's say, an October interim or for the November meeting in San Francisco. Is there any agenda bashing stuff we need to add? Do you wanna do these in a different order? Have I got the wrong names on anything? Any any edits to the agenda?
[00:04:31] Richard Clayton: Richard. I think we should probably at least have a very brief discussion about character sets and perhaps do that before the PQC signing and so forth because the other things can can drift out. Whereas I think having a quick discussion about that in person will speed up what we do on the list.
[00:04:56] Murray Kucherawy: Okay. So character sets between flags and PQC. Anything else? Any other edits? Okay. Richard, I think you're up then for from header field authentication. I will give you slide control in just a moment. And I wanna give Richard okay. You're in the driver's seat.
[00:05:29] Richard Clayton: Okay. Right. This is everybody here is an expert on email, so this is just getting the jargon correct. Recall five three two two has described header fields, so you have from colonrichard@example.com in the top of your email. And when it is sent over SMTP, we see a mail from richard@example.com to show who the mail is being sent from. These usually match, but they may not. So sometimes we use the jargon, the five three two one envelope, because of the notion that inside the letter inside though the letter though the envelope is addressed to Richard, inside it may say, dear Fred, and that sort of thing happens. Now DKIM2 requires the mail from tag to match the mail from which is actually used on the wire at every hop, and the validator will check that this has happened. And the implication, if you forward the email, is that that was done. But there's no way of checking that it was actually done. It is just recorded that it happened. It's one of the few bits of Deakim two where we have to trust rather because we cannot verify, because we cannot see the actual conversation. We don't have a PCAP. Okay. The the RFC five three two two from is important for DMARC, and DMARC is a check that this is, in some sense, valid. The domain name from it is used to find the DMARC policy record in the ZNS, and then the email is assessed to see whether or not it has, in the jargon, an aligned DKIM1 pass or an aligned SPF pass. And if it doesn't have an aligned pass of either of these two things, it'd be one or the other or both, then the policy bit of it, the p equals reject quarantine or whatever, will, is a request from the domain owner what you should do with mail for mail which does not have an aligned pass. And the alignment can either be strict or loose, and I'm not gonna go into detail of that because we don't care about it today. Okay. So in dkim2, we cope with people who mangle from header fields. Intermediaries mangle from header fields. This is typically done by mailing lists because they are going to alter the content of the message, which causes the d k m one signature to fail. And clearly, because they're a mailing list, they won't be in the SPF record for the domain. And therefore, when they forward the the mail to somebody from the mailing list, there will not be an aligned pass. As a result of which, the mail, if it's marked p equals reject, may get rejected. So what mailing lists often do is to mangle the from so that they write a from which belongs to the mailing list rather than to the rather than the original one. It's just now because then when they send the mail on, then the IP will reject policy will not kick in as a result of which the mail will not get rejected. Now if we have a chain which is entirely in the Dkim two world, then we can cope with this because in Dkim two, when you make a change like mangling a from or for that matter, changing the body and adding some footers or whatever to say this come from mailing list, then we can recover the original state of the email before that mangling was done. However, at the moment, DKIM2 has nothing to say about what the r l c five three two two from header field should actually contain. All it does is it has a mechanism so you can recover the original one should you wish to do so. And you might you will wish to do so in order to be able to check earlier signatures. At the moment, today, d a DKIM2 pass or indeed a DKIM2 fail has no meaning whatsoever to demark. And Wei is going to talk about what we might do about that in the next section of the of the meeting. But the rest of this slide deck is about what Dkim2's specification requirements might be, and I'm not gonna mention DMARC again anywhere in this deck. Okay? So what we decide as a result of the next few slides may color what we talk about when Wei presents, but whatever we do or do not suggest doesn't, in ways bit, doesn't affect this proposal one way or the other. They're kind of orthogonal to each other. They may seem related, but but strictly they're orthogonal. Anyway, the proposal is that a from header field in an email must be authentic. I'm deliberately choosing a different jargon than the demark jargon so that people don't get confused about mapping this onto demark. This is a completely separate concept. Not unrelated, but it is it is separate. And the suggestion is that if you put a from header field into an email, it must be authentic. So what the proposal is to change the DKIM2 spec to say that when the signing domain that the signing domain used at hop I equals one, I e when the email is first created, And, also, at any hop where somebody changes the from header field, then the domain in that from header field must match the the the signing domain. Right? So so if you have from richard.example.com, then anybody who puts that into an email, then the the d equals value for the for the Deacon two signature at at that hop must be example.com, and it must match. We will use for what we mean by a match, the same strip off the subdomains match that we already use for the m f equals value. The reason for using that type of match is that we don't end up looking at public suffix. So this is lists or, walking, DKIM walking DNS trees or whatever. We can just do it statically without doing any any lookups at all. And we don't think that this is an onerous, requirement on the senders of mail because we think that everybody who actually sends authenticated mail today does this. Right. So why don't we just say that you have to do this at I equals one? Why do we say it for everybody who was in a a new from header field? And the reason for this is that if the MUA who actually gets this email might may or may not be sufficiently aware of what is going on to either take the from header field, which comes straight out of the the message which has just been handed. Alternatively, it might be capable of knowing that there used to be a a from head of field before some mailing list mangled it, and maybe the person who actually handles that mail, the the MTA, might have been in a position to pass that information onto them so they could use that and basically hide the fact that the the mailing list has mangled it, which might reply to work a lot better and and stuff. So MUAs might be keen to do this, but they won't necessarily do it, in the in the short term. So they may use the from they have to hand, and therefore, we would like that to be, authentic in the same sense as the I equals one is authentic. Again, everybody who mangles things and doesn't does any signing or authentication of what they said, they do that today already. So we're not we're not in practice asking for anybody to do anything different. What we're doing is we're actually gonna write down that they must do it. And then the question arises, what happens if you get an email where somebody has taken no notice of the spec and has created a mail where the the from header field does not match the d equals signing domain. The option one is that we write into the spec that they should reject it, of course, on the basis that this mail is not valid. It's not validly signed. Almost certainly something bad is going on because people are trying to imperson they're they're writing down the mail is from somebody or other, and and it's not actually them because they're not in the position to sign it to say it's them. So it's not authentic. Of course, local policy, you can accept it. Local policy, you can do anything you want, but we write in the spec it should reject. The next option is weaker than that, and we write in the spec that we may reject. That creates a bit of a problem if you decide to accept it because you can't be bothered with the may, and then you send it on again to somebody else who's Dkim2- aware who is operating their May on the basis they are going to reject it, because that's gonna be your problem because you're gonna be forwarding mail which people won't accept. So that messes things up a bit, because the sender who will eventually get the bounce, the the DSN, might get a little confused as to what happened and why. Option three is we write down that you should not reject it, and we say, well, this is all gonna be done at some other layer and so forth. I offer you that option not because I think anybody's saying they're going to accept it, but we might as well have it on the page. And then the option four is we don't say anything at all about what you should do, and we leave it to the BCP to try and write some text about this and how you might do it. And probably the BCP is gonna say times will will change. And in the future, a policy which seems sensible to you today will will seem insane down the line. And those are the slides I have on this topic.
[00:16:32] Murray Kucherawy: The floor is open. Do you have let let me let let's go and create a starting point here, Richard. Of the four options, which would you pick?
[00:16:44] Richard Clayton: I I would pick should reject.
[00:16:46] Murray Kucherawy: Should reject. Thanks. Allen.
[00:16:53] Allen Robinson: Alright. So the reject word here, I think, is incorrect. I I know we we've we make a lot of simplifying statements in a lot of these debates. But what DKIM2 should be saying is that it should not authenticate as Deacon two. There might be other authentication mechanisms that do pass, but it should not be considered a DKIM2 pass. And then what you do if you have an email that doesn't have a DKIM2 pass is sort of local policy because there's a bunch of other factors that that come into play. So that's sort of minor minor note there. I think I think we we can maybe be a little bit stronger in in what we're saying, which is that it must not be considered Deacon two authentic in that case. So sort of an option five. Right? Because because if you separate whether it's authentic or not from what you do if you have a DKIM2 unauthenticated email, like, you you've got a little bit more room to move. I I would agree that option three and four are aren't good, and option two doesn't really say anything because you can choose to reject email for any reason. So it doesn't like, that's that's already true.
[00:18:28] Pete Resnick: Yes. But
[00:18:28] Richard Clayton: but if you wanna accept it for some other reason, that's essentially your local policy, isn't it?
[00:18:39] Allen Robinson: Sure. But, like like, you should you should reject, I I think, is is maybe too strong of a statement, particularly in the, the reality of the world that we're gonna be in for an indeterminate amount of time, hopefully not too long, but maybe, where there are other authentication mechanisms that could make this email acceptable. So I think we need to be careful about about saying, like, it will always be rejected. I think that's all I had for this.
[00:19:17] Murray Kucherawy: Okay. Thanks. Tobias?
[00:19:21] Tobias Herkula: I think we we had this discussion from the beginning, and one of the goals in DKIM2 is, like, that is an answer more to Allen than than here because I'm for option one here for sure. I think the goal for DKIM2 is that if we have a broken chain that we reject and therefore do not have all the spec backscatter problems or forwarding problems that are currently inherent with which with Deacon one SPF and nonauthenticated mail. So I would say option one is the right way to go here because if if we say that if the alignment does or if the authentic property of the header from is not given anymore, then we should reject the message. So be because we essentially say dkim2 is broken, the chain is essentially a dkim2 message, and therefore, it should be rejected. And the hop before should be aware that, hey. You can't deliver that mail anymore because DKIM2 is not valid anymore.
[00:20:30] Allen Robinson: But but in the in the period where not all systems are DKIM2 aware, I mean, I I guess in that case, the DKIM2 chain wouldn't be valid. So it's it's not a DKIM2 message anymore.
[00:20:45] Tobias Herkula: Exactly. So this is this is the wording only for the case that that it's a valid Deacon two chain, essentially valid, but the authenticity of the authenticity property of the from header is not given anymore because of a change that could be a replay or some other kind of attack. Because I think non DKIM2 messages or out of chain messages are not in scope for the discussion at all.
[00:21:19] Allen Robinson: Yeah. If the if the from field had changed by one of those systems, the signatures wouldn't pass anymore.
[00:21:24] Tobias Herkula: Yeah.
[00:21:24] Allen Robinson: That's true. Yeah. Okay. I'll have to think about that. That's some more.
[00:21:39] Murray Kucherawy: Brian?
[00:21:41] Bron Gondwana: Yeah. Hopefully, you can hear me in at least one ear. So there's two different things being discussed here, one of which is should reject, and I think the terminology on that is actually wrong. It is should not be treated as valid DKIM2 would be the actual phraseology we should use here, and then you should your local policy is whether you reject things that are not valid DKIM2, and that gets rid of that part of it. The other question there is whether you can bounce back regardless of this, and the answer to that is an unequivocal yes. The RFC something ending in two from header has absolutely no bearing on where you bounce back to, which is the something ending in one m f equals mail from over the wire, and that's where the bounces go back to. And it doesn't matter what you lied about in the from header, the bounces still go back to you, the domain that signed the message, so that's not a problem. They were the they were the two things that were coming up in that conversation that didn't seem to make sense to me. It it shouldn't be a should reject. It should be a not DKIM2, and it's it's got nothing to do with bouncers.
[00:22:55] Tobias Herkula: Oh, sorry. But but I I would like to to counter that front. I meant that
[00:23:00] Pete Resnick: Jump in. Go ahead.
[00:23:01] Tobias Herkula: That the the discussion we had, like, DKIM2 in itself, the aim is to reject if DKIM2 is not valid at the point of when I receive the message. And therefore, I should reject the message because DKIM2 is invalid or the chain is invalid to me.
[00:23:19] Bron Gondwana: That that That's definitely a case where the BCP should say you should reject things where DKIM2 is invalid rather than the spec saying you should reject. The spec should just say DKIM2 is invalid.
[00:23:31] Tobias Herkula: No. So but that was my argument. So so I didn't want it to say that we should write into the spec we should reject, but I I'm aiming for yeah. It should say that DKIM the DKIM2 chain is invalid if that authenticity property is not there anymore.
[00:23:46] Wei Chuang: Yeah. Okay.
[00:23:48] Bron Gondwana: I didn't I realized I didn't answer the question that is on this slide. I think the BCP should should answer this. The BCP should say, you shouldn't trade Dkim2 as valid if the authenticity property doesn't apply. But the spec itself doesn't require that layering violation level because the the envelope, which is the wire component of it, is still completely valid all the way through and the bouncing properties are still completely valid all the way through. So it then becomes the policy of whether you treat that as being valid or not and that should be BCP.
[00:24:33] Richard Clayton: Pete.
[00:24:35] Pete Resnick: So I luckily for me, Bron said, everything that I was hesitant to say myself. Here's my question. And, you know, you you heard my little spiel on the list that I I think this needs to be called out rather directly because this is a change architecturally from DKIM one. What happens in the case where, the mail from domain doesn't match the from field domain? Am I simply not allowed to have such a case? If I put both signatures on, is that okay?
[00:25:26] Richard Clayton: What do you mean by both signatures?
[00:25:28] Pete Resnick: I I I have a message where from is gonna be from resnick@pete.com, and the mail from is gonna be mail from resnickhandler@someotherguy.com. If I sign the message with a domain of pete.com and a doe and then sign with a separate signature with the domain ofsomeotherguy.com.
[00:26:04] Richard Clayton: That's kinda what
[00:26:05] Pete Resnick: does. Valid message?
[00:26:06] Richard Clayton: Yes. Of course. This is what ESPs do all the time, which is they send the brand sends it notionally to the ESP. In fact, it's it's created on the ESP's platform, and the ESP signs it with the brand's key, which the which the ESP happens to have in its hand because the brand has done a c name in order to ensure this happens without secrets going all over the place. So the ESP port on I equals one signature for the brand, which will match them which will match the which will match the from, the five three two one header field from. And then it puts on a second ESP then puts on a second signature and the mail and puts a mail from on that one, and sends it out on the wire with the ESP's signature matching the mail from, but not matching the r c five three two one from. And any forwarder down the line is going to do much the same thing, which is they're gonna send it onwards with a mail from which reflects whatever they're doing, whatever their forwarding is, but they're not going to alter the from colon in the headers at all because there is no particular reason for them to do so. If they are a mailing list or something like that, they are going to change the from colon and for to mangle it or whatever. If they do that, then they're gonna have to make sure that whatever they put in the mangled version matches the signature which they're going to put on their particular hop.
[00:27:40] Pete Resnick: Okay. So the mechanism, but
[00:27:43] Wei Chuang: so let
[00:27:43] Pete Resnick: me ask.
[00:27:44] Richard Clayton: We got rid of the invisible hop by having it not declared so you don't have to invent a mail from which never actually happened.
[00:27:52] Pete Resnick: Right. So let me be let me ask further. So the the mechanism itself, the spec is gonna say, here is my signature, and the signature is signing with the domain of either the mail from or the 22 from.
[00:28:09] Richard Clayton: There's no no either
[00:28:12] Tobias Herkula: or both. No.
[00:28:15] Richard Clayton: No. There is no there is no either because the I equals one, if the if there is a mail from and there's a transfer over the wire, then everything must match. And at the next hop, all you need to do is to match the mail from you know, match the SMTP envelope. That's all you need to do. Right? So And so And so you should avoid changing the from.
[00:28:42] Pete Resnick: So so there is an implicit if I'm going to send a message with a different mail from than it has a from field, there is an implicit extra hop, and the extra hop must come second.
[00:29:01] Richard Clayton: Yes. So if you have if you have if you are sending email for six different domains from your private server, but you wouldn't send them all out with a mail from of the server because you want all the bounces to come back to you as the postmaster or something, then you are going to have to put on two DKIM2 two DKIM2 signature fields.
[00:29:26] Pete Resnick: And they must be in a particular order. The first one better be the from, the the from field of the fifty three twenty two.
[00:29:35] Richard Clayton: Abs absolutely. But you can use the fancy short circuiting stuff we developed for the ESPs in order to
[00:29:42] Pete Resnick: Mhmm. Okay. I will
[00:29:47] Richard Clayton: Claude will help you out.
[00:29:49] Pete Resnick: I I will repeat that I would like this to be very explicit in the spec that you know? Because, honestly, you could do them in any order if you had a flag in the signature line that said which domain you were signing for, the the mail from or the 5322 from. But if order is the important thing and you want I equals one always to be the 5322 from, that's a choice.
[00:30:20] Richard Clayton: Yes. I I I will treat you as a participant here because I don't think
[00:30:25] Pete Resnick: Absolutely.
[00:30:26] Richard Clayton: Don't think I like an instruction from a chair that says that I should be explaining how to do it in a spec, whereas a whereas a BCP is the correct place to provide a kind of advice for you. The spec No. Will say what it says. But from time to time clear.
[00:30:46] Pete Resnick: I wanna be clear. All I'm saying is the spec needs to lay out these steps quite clearly. Not the operations, but the fact that the first signature must be the 5322 from Yes. Signature. And thereafter, you can sign if you change that, you can sign. If you put on a mail from and that mail from is different, you can sign, etcetera, down the line.
[00:31:14] Richard Clayton: Okay. I I will I attempt to add a small amount of text indicating that you should pay attention if nothing else.
[00:31:23] Pete Resnick: Thank you.
[00:31:26] Murray Kucherawy: Tobias again.
[00:31:28] Tobias Herkula: So, yeah, as a hint for Pete and and also to to go on on a little bit on that. So the the thing is that it it's not specific to the first instance. It's it's more like the first instance always have to be authentic. So the first time, it's all like, the DKIM2 signature with instance number one always needs to have this authentic property so that the header from domain matches the DQM d value. But it could also, at the same time, match the mail from, so you don't need a second one. If you really have a second one, you can have a second signal shown instance two, but in your in the same ADMD at the same time of signing, and we even have an an a special property for that that's called n d where you can do that, and then it don't even need any mail from or anything for the instance one because n d tells, like, the next domain is relevant for the mail from and the r c p t two stuff. So you can do that in one shot. You don't need multiple hops or anything like that. So only I one needs to be authentic and can be can be matching the mail from. With n d, you can say the next hop will sign my mail from, but hop only means essentially the next instance of the dkim2 signature. And on the other hand, every time and that's the wording that that also most likely comes into play here. Every time an instance later in the chain changes the from header also needs to have this authentic property. So if on the fifteenth forward ADMD suddenly changes example.com to example.org, then he also needs to sign with example.org so that the chain the authenticity of the visible from that is shown to the recipient is always there.
[00:33:47] Murray Kucherawy: So, Richard, do you have what you need for now? It sounds like something we put I mean, we need to confirm consensus on the list anyway. But anything else you wanna cover on this topic?
[00:33:56] Richard Clayton: No. I I think that nobody is saying this is a silly idea, so I will include it in the next version of the spec Okay. And pay attention to what was said and what is in the chat to make sure that I've covered as many points as possible. So, yes, let's move on.
[00:34:13] Murray Kucherawy: Okay. Thank you. Moving on. First, I reclaim slide control, then I stop sharing, then I go let's see. The next slide deck is Dkim two and DMARC revision one. Everybody see that? Can someone see that?
[00:34:41] Pete Resnick: Yep. You're good.
[00:34:42] Murray Kucherawy: Okay. Good. Wei passing you control. Take it away.
[00:34:48] Wei Chuang: K. Let's see if I can work these controls first when I've done this. Yeah. So let's talk about how DKIM2 and DMARC can work together. Great. It works. Okay. So, basically, you know, the challenges for DKIM2 is that the current DMARC RFC nine nine eight nine does not say anything about DKIM2. A lot of places, including us, we very much depend on DMARC. I think there would be I think there's a great deal of interest to to see how, you know, DMARC will interoperate with DKIM2. And then so that is one of the challenges. The other thing is basically DKIM2 can provide potentially a great deal to DMARC. One of the challenges for the existing DMARC ROC is that things rewrite the from. And, well, there's things that modify the message that breaks authentication. And then as a response, there is, that rewriting of the from. And that is something that DKIM2 is very good at resolving. So but then the challenge now becomes which one of these from header field, you know, which one to use. And another issue is that there is this notion of a demark policy, but DKIM2 now introduces this flag policy. And then what what do we use? Because they seem to sometimes potentially, in some instances, conflict a little bit. So there's other challenges for DKIM2. And this is an area where, you know, I think perhaps DMARC can play a role, and then maybe it's worth exploring what these things are. So what worries me is that you can introduce all of these DKIM2 signatures to messages, but then an attacker in the future may just go over to that message and strip it and then carry on, without any of the protections that DKIM2 has. Another issue is that as we deploy DKIM2, we're going to have to find a way of working with Deacon one. And by doing so, we actually open up holes again that DKIM2 are meant to solve. And if we don't find a way to interoperate in a clear fashion, meaning outside of local policy, I think we're going to basically be back in the same place where we were before where we play is very much a prevailing problem. And we should really think about that, the whole sort of, Dkim and Dkim2 interop story so that we plug those holes so that it doesn't become a problem during bringing up the same problem that we were trying to solve in the first place. We also want to prevent, you know, in that interrupt story creating a flag day. And, basically, it it it's something that we should really think about, I think, from the beginning. And I think DMARC can play you you know, like, the DMARC policy mechanism can play a role here, and we'll talk about that in a moment. So I put out a draft to try to put together these different ideas. The claim in the beginning of that initial post is if we can think about this holistically, I think we can make a lot more progress. Meaning that, like, if we think about all these kind of different problems in one place, and I understand why there's a desire to kind of break it apart into each each component and then try to think through each of these one at a time. But I think if we allow ourselves to go think about this in one document, then we can find more solutions, basically. And let me just go through some of the the ideas in this particular draft. In particular, of course, it calls upon DMARC RC nine nine eight nine to support DKIM2. It calls upon a notion of having the identifier authenticated identifier lookup at the DKIM2 signature I equal one. This implies that alignment must be on I equal one. It calls for the introduction of a DMARC DNS policy auth equals tag that defines which authentication is going to be present on the message. It also calls for, mediating, basically, the policy mechanisms between DMARC and DQIM two. Basically, this notion that there is an enforcement policy or domain level policy that's distinct from a per message flag policy and that DKIM2 carries the flag policies while DMARC carries the domain level policies. Let's get into some of these four major bullet points in the next set of slides with examples. So first, there is this alignment at DKIM2 signature I call one. Basically, this calls for evaluating the chain of custody all the way to the I equal one and then recovering the from header field and using that, particular, authenticated identifier to look up the, DMARC policy. It's going to, you know, use the relaxed procedures and and at least for D Kim two. It's going to take the read the policy and evaluate the policy, the DMARC policy, from from that authenticated identifier. There was in the earlier versions of this, it called also for potentially evaluating at the highest I equal n, but I think there was strong feedback, pretty much unanimously that that was a bad idea. So that has been removed in the later revisions. And I would assume that since it's unanimous, there's probably not a whole lot to discuss there, but we can discuss as necessary. Then, basically, yeah. So if just calling, basically, you know, we're going to use the support for DKIM2 to recover that from header field. And it's an explicit choice not to use the intermediate ones, rather to go use the one that's at the I equal one. The document calls, that is going to represent basically the author's entities, basically their policy. That, you know, the the sort of philosophical viewpoint is that, like, intermediaries are there to support what the author wants to do. Next slide. Okay. So next, this is introducing this DNS policy auth equals tag. This is a way of representing which authentication is going to be present on the message. It can be you know, there can be a comma separated designation of of the mechanisms, you know, DCAM, DCAM two, and SPF. By default, if if this particular, tag is not present, which is going to be in all of the message you know, all of the policies that are, say, in the DKIM1 world, it would, by default, be Deacon and SPF. DKIM2 is explicitly left off so that it forces parties that want to use and declare a decompute. They have to do so explicitly because then that allows this to become a capabilities lookup mechanism. And we can see some applications of that shortly. It the document says that also this is a optional mech optional tag so that it may be that a domain, perhaps during, say, the bring up phase of DKIM2, can still, of course, use DKIM2 and not have to publish this. And that is something that has to be accounted for. This also, calls up for the concept of as a capability mechanism, we can do a forward lookup to see if the, receiving receiver is going to support DKIM2. And if so, then and we find that the receiver does not support DKIM2, that there can be a mechanism to terminate the chain of custody so that we don't, cause downstream, basically rejections of, trying to have messages reenter back into Deakim two world, essentially. So let's go to the next slide. Okay. So here and, I guess there's a queue. Should I take questions or keep going?
[00:45:19] Murray Kucherawy: It's up I think it's up to you if you wanna have discussion now. That's fine if you wanna push it all to the and and how many slides do you have left? You have four to go.
[00:45:26] Wei Chuang: Yeah. Four to go.
[00:45:28] Murray Kucherawy: Your choice.
[00:45:28] Wei Chuang: What's your preference? I I see here if I just keep going, but, I mean, I'm happy to Okay.
[00:45:35] Murray Kucherawy: The the queue can wait for you to be finished. That's fine.
[00:45:38] Wei Chuang: Okay. Alright. So the the next this this is an example here of, you know, the header stripping scenario. Basically, what a mail receiver can do is go look up the policy at the authenticated identifier, see that, like, they were supposed to have sent with a DKIM2 set of headers. None were present, and that is a sign that someone in the middle of the chain decided to strip out the headers and then potentially enforce upon, you know, the fact that there is missing authentication that was expected. And you can see, basically, in this example, like, you know, the example on the left is just at the bottom there. It's basically the message without the headers, the expected decompute headers. And the thing on the right is basically the demark policy with the auth equal and the decompute mechanism present. In this second example here, this is that example about trying to support the interop case where a message is going from the DKIM2 world to DKIM1 and then potentially may be forwarded back to the DKIM1 two world. And then that causes a a risk that there is basically, at that point, the traffic is going to be indistinguishable from replay. And where this was actually a benign forwarding, it just went through a naive DKIM1 forwarder. And what is meant to do here to support this is we create an indicator essentially that this message was benignly not going to ever then again match the chain of custody, and we set the RT to basically be empty. And a DKIM2 mail receiver is going to then see that and say, okay. Well, I can't validate the chain of custody anymore. So I'll I'll basically I'll I'll know that it went through DKIM2, but I know that the the receipt two matching won't work anymore. And then we'll we'll the mail receiver will say, we'll stop doing that. And rather than just, you know, be confused by the fact that it looks like otherwise, it would look like replay and thereby, enable interrupt. And then this is just saying that there is, as mentioned before, this notion that there are DKIM2 flags. There are policy mechanisms per message that the enforcement mechanism would come from DMARC as a domain of a policy. And the document tries to go to some length to say, well, there is potentially with these different flags, different members of the chain are going to influence the evaluation of the flags. And so I went to some, length to try to describe that. I think, I won't belabor that too much because I think there's going to be a much larger discussion around flags in the next set of slides. It's just that I wanted to point out that there is a section in the draft basically trying to talk about the, interrupt between, say, the different parts of a DKIM2 chain and a particular flag, but between different flags, like, say, explode and, do not explode, etcetera. So just wanted to point that out. And then this is, I think, the last important slide, but this is an example here to show, basically, another, interop scenario between messages coming from, Dkim to Dkim two and supporting that use case. Basically, I should have pointed out here, there is a one particular flag here unaligned that's meant to designate this particular special scenario between messages coming from DQIM to DQIM2 and then starting the chain. And then in that particular scenario, it's going to suggest that, yes, we're supposed to have this, alignment at I equal one unless we have this unaligned, in which case then it came from DKIM1 world, and we're going to look for the policy there rather than in DQ-two. And, again, it's meant to support this particular scenario, where we want to potentially support messages coming in from DKIM1 world into DKIM2 and say this is a permitted scenario by this forwarder. It also helps designate that this is a Dicom2 forwarder that supported this scenario. And I think that's it for the major parts of the slide. I guess I can take questions. The one other thing I wanted to point out is as the next step is to probably cross post well, first figure out what, you know, what is our people's reaction here. Assuming this is of interest, then I can cross post it to the DMARC working group as well.
[00:51:24] Murray Kucherawy: So before we start turning before we start turning through the queue, I wanna point out we are fifty three minutes into a two hour meeting. We've covered we're in our second of six topics. So let's we can try to keep this brief. We can get through more. Otherwise, there'll the overflow will will will will work it that way. Go ahead, Bron.
[00:51:42] Bron Gondwana: I was gonna say the RT equals blank for passing it on to a non DKIM2 supporting Next hop was something in my original proposal for this a long way back, but it was we decided against it because it required an extra DNS lookup on every send, and it required not only updating your software as a receiver to handle DQIM two, but also adding a DNS record. And if you don't have that DNS record, then DQIM two will always break because we're not sending it out in anticipation of it maybe being handled by the next hop. So that opens up a pretty wide additional discussion because it's a change in behavior for the sender based on what it sees in DNS. And also means that if you have any DNS temporary glitches, then the message is gonna lose its DPM two status along the way. So that I think we need to have some more discussion around that point anyway.
[00:52:44] Wei Chuang: That's that's all I have. It's in yep. I agree that it's in point to discuss that. I recall right there was early discussions around this capabilities mechanism. Sure. I think it's a good idea. I think the risk around doing these DNS lookups, it can be somewhat mitigated because this is most likely something that I think the DNS system is going to have to often look up anyways because it is around the demark policy that's often looked up. I think that the it you know, the risk is, otherwise, we're going to run into sort of this interop scenario where a lot of messages will be in the beginning, especially during bring up with Deacon two, are going to be sent to Deacon one only receivers that will then potentially forward on to dkim two again, and then that will break things. We're going to have, otherwise, a lot of
[00:53:45] Bron Gondwana: I guess the question is what's broken. You either receive something with an r t equals blank or you receive something with an r t equals the address it was actually sent to at the next hop, either way, DKIM2 is broken in exactly the same way. So you can tell that it exited DKIM2.
[00:54:04] Wei Chuang: I I think the difference is that a DKIM2 receiver can be told that the chain was intentionally broken or it was broken because of replay. There's a distinction there in one is a benign case and the other one is going to be a malicious case.
[00:54:19] Bron Gondwana: It was intentionally broken by by that hop saying it doesn't support DKIM2. You can tell that by checking its its D Mark record as you receive the next hop rather than checking it as you send. So I I think it has value there, but I don't think it needs to be used to suppress the RT equals field in the signature. I think you might as well still leave that in anyway. And then the next hop, when it receives, it should check whether there's a a record that says this hop this domain should have supported DKIM2. So the fact that it that the message got forwarded on without it is a problem.
[00:54:59] Wei Chuang: I think there's right now, the design is kind of oriented towards it it means a forwarder has to do some extra work for looking up the DMARC policy. A receiver can pretty Alright. Much
[00:55:14] Bron Gondwana: Hop a sends a message to hop b. So hop a is DKIM2. Hop b is not. Hop c is. So in the way you defined it, hop a sets RT equals blank is because it knows it's exiting DKIM2. My proposal is that instead hop c receives this message and says hop b didn't sign this. Does hop b advertise that it supports Dkim2? Because if so, then this is bad. If not, then it's the same. But hop a doesn't need to do the forward lookup. Only hop c needs to do the backwards lookup. So I think I think the underlying mechanism is good, but the r t equals blank is not necessary. It doesn't add any useful information to anybody, and it has failure modes.
[00:56:04] Wei Chuang: Well, so I agree what your propose your proposal will work as far as I can tell from the brief moment I I just heard it, but I believe it's just who is going to do the work. And then so in this particular proposal, we're going to be, you know, requiring a DMARC lookup on the I equal one. And then the forwarder, if it wants to go forward messages, will have to do some extra work, and it has to go look up that DMARC policy of the mail receiver. The next I think we should write
[00:56:36] Bron Gondwana: up the cases here. I'm happy to do a write up of of the different cases because I think there's no additional there's no additional work for hop b because they don't know anything. They're not Dkim2. And there's no additional work for hop c.
[00:56:50] Wei Chuang: We're not asking b to do the extra work. It's it's basically the the sender. Either they do the work or it's going to be the receiver that does the extra work.
[00:57:00] Bron Gondwana: Yeah. But the receiver has to do the work anyway. So I don't think it makes any difference. I'll I'll write it up, but I don't think I don't think c has any difference between the two cases. Either way, the chain is broken and they have to figure out why, And the the dkim the d mark record for domain b will tell them whether this was a left DKIM2 or a replay attack on domain b. And so either way, domain c is gonna have to do the work. It's just whether domain a needs to do the work. And I don't think it does, and I don't think it I don't think it has any value.
[00:57:41] Wei Chuang: Well, let's yeah. Let's do the write up. I mean, I I think I think we can puzzle out who has to do the work, and it it could be just a matter of figuring out who is going to be the one that has to do it. And you know? But yeah. Let's go write it up, and then we can put that the discussion out on the mailing list, and we'll figure out from there. I guess, Richard?
[00:58:09] Richard Clayton: Okay. Trivial point. Do not cross post between mailing lists. It all goes wrong.
[00:58:16] Wei Chuang: Okay.
[00:58:17] Richard Clayton: Post post in parallel to the mailing list or draw people's attention to a discussion on another mailing list. You cross post, people reply. It all gets really messy. So don't do that. Now I am very much in favor of your auth equals stuck into a DMARC record saying auth equals DPM two. It solves the stripping problem, and it solves it in absolutely the right place because it solves it in the record which a dkim one aware a dkim one aware, but updated handler can deal with. In that it will look at this message, and it will say, this is validly DKIM1 signed, but I expect more, and I'm going to reject it. So it is not part of a DKIM2 flow at all. Right? It is part of a DMARC and d and Dkim one flow, and it is in exactly the right place because it's in a a record which you're going to look up anyway. So I think that's a great idea. If you are going to write down auth equals SPF, I think you're gonna have you've got a can of worms there because what happens if I have an SPF policy which deliberately doesn't pass because I'm going to send from a cloud, and I'm not gonna publish a d a passing d SPF policy because I do not wish to say that any IP address in this cloud can send as me. I'm gonna say SPF doesn't work. Alright? And I'm going to deliberately set up my SPF records so that that happens so that happens with the correct syntax. So you will need to think that through, and I'm not sure it adds anything here. But auth equals d k m two certainly has value, and anybody who cares about their mail is going to want to add that. If they don't add it, no no harm done or at least but the harm done is people can strip, which is an exotic situation. If it starts happening to them, they can rapidly publish the policy, and things will get better for them. Right. I am extremely worried about the notion that you can do forward lookups, right, and decide what domains of a sending domains policy and work out anything useful. Because the domain to which you are sending, right, you're gonna be looking up MX records and so forth. Domain to which you're sending is not necessarily exactly the same as, is not necessarily a domain which is going to be sending mail. Sending mail and receiving mail are different. The domains do not necessarily match, and the policies do not necessarily match. You may not actually have policies on the domains to which mail is being sent because those domains never actually send any email. So I think you need to rework that. If we do what Bron suggests and we do it at the point at which mail arrives, that's much better because you know where to arrive from, and you're not trying to guess whether a lot of things match up. Right? The next thing is that I see no value whatsoever in in receiving a DKIM1 message and putting it into the DKIM2 world. It does nobody any favors. It's not going to improve its deliverability at all, and it doesn't help adoption or anything. You might as well just forward it on as a DQIM one message and pretend Dkim two does not exist. You get Dkim two messages, forward them on as Dkim two, of course. Right? But but people will be signing as both Dkim one and Dkim two going forwards. If there isn't a DKIM2 signature there, don't put it into DKIM2 world because all those sorts of things get complicated, and all sorts of policies get ruined. So don't stop pretending that you want to make it a DKIM2 message. Just send it on the way in which you'll send it on today, and everyone will be perfectly happy. And if they want all of the nice new features of DKIM2, then they will get with the program and implement it. But if they if they haven't done that, then don't help them out. Just leave them in their own little world of DKIM1, and they can stay there. I also I'm a little concerned about the notion of a policy per message because I think people will start using it, and they may start putting p equals reject on valuable messages like sending out invoices. But password recovery, they might put p p equals none on. And then if you can take a password recovery message with a local poll with a per message policy of p equals none, then you might be able to amend it and change it and send it onwards. Right? And then they and then because you have changed the body, then, p equals reject would be far better, but it is this particular message has a p equals none policy on it. So I think your policy needs to be per domain. If you want a different policy for different messages, then use a different DKIM key, a different selector, and send it out with a different policy.
[01:03:42] Tobias Herkula: Okay. But then I I would argue about the flex in itself because I don't think there's that much thing left in the DMARC world if we have a DQM2 adoption because we would most likely already reject if DQM2 fails and no other authentication schemes would allow me to process a message. So p reject is essentially implicitly assumed. And I also already started on the mailing list a discussion about the other flags with do not explode and do not modify. Both, I think, is is something that should not be part of DKIM2 and should be only in the DMARC thingy. So I think what we should do here is we we try to figure out what policy needs are left after we have DQIM2 and then update d Mike with what is left on the field, like dep perhaps deprecating SPF or deprecating DQIM1 at some point and then bring up some policy stuff that then the group can decide if that is worthwhile to to do or not. Because I don't think we should put any policy flags into the DQM two spec at all and not trying to bring any DQM two to DMARC right now because we don't know yet what will be left with DQM two in itself of DMARC.
[01:05:16] Wei Chuang: I mean, we'll have a discussion on the flags, I guess, in the next section. I think, I I I mean, I see value in in these flags. I guess we can talk about it then, But I can understand how it is a policy as opposed to authentication, and, you know, there's a need to kind of move the policies things into the right document, if you will. That makes sense to me, if that's what you're trying to get at.
[01:05:50] Richard Clayton: Okay. Thanks.
[01:05:53] Murray Kucherawy: So I see where your last slide here is even saying, part of what you wanna do is go get feedback from the DMARC community, the DMARC working group. Is there any any is there anything else you wanted to get from here as in terms of guidance to do that, or is that the next the only next step? Do you have a document you wanna introduce? Like, what is that is that that all or something else?
[01:06:14] Wei Chuang: No. What what I was going to go I mean, what I was hoping to do is get feedback from the working group. I will Yeah. Take back what, Bron, Richard, and Tobias said, and then, I will update the document, rev it one more time before sending it off to the DMARC working group. And then just put out get comments from the list before I think you know, like, I think, basically, it needs to be ready enough from this group's perspective before I want to go send it off to DMARC largely because, you know, I I need an an investor suit already just so it's better to know that it's got the support of the this working group.
[01:06:53] Murray Kucherawy: Right. So there's gonna be probably a couple of iterations on our list before it goes over there is what I'm hearing.
[01:06:58] Wei Chuang: Yeah. I think that was one iteration, I think.
[01:07:01] Murray Kucherawy: Okay. Thank you, everybody. Let's go onward. I'm I'm taking the slides back. Cancel this. Start. The next one is Richard, I believe. Dkim2 flags and giving Richard control once again.
[01:07:21] Richard Clayton: Kick it away. Okay. Once again, everybody, of course, read the spec many times, knows all of this. Just to remind you, there is a flag in DKIM2. And in DKIM2, we are writing out the flags as dictionary words rather than single characters. We could change that if people are concerned, but for the moment, they're seeing they're dictionary words. If you put a flag on a message that says exploded, it means that at this hop, one mail was received and one or more copies was sent out. And this will be used by receivers to spot undeclared replays, And it may help to auto detect mailing lists because you may have different policy that you apply to mailing lists and that you may not chop their legs off if they send spam occasionally, whereas you may treat other senders more less leniently. Nobody has ever reported any interop issues with this or the an inability to work out when you add this flag. The only thing there's been a discussion of on the list is that if you only receive one copy of an email, you have no idea whether or not an undeclared replay is going on. This is this is, to some extent, a feature for large mailbox providers who have lots and lots of mailboxes and do see replay on a regular basis, and spotting undeclared replays is an important part of Deakim2. So we so we want that flag. Okay. Next flag is feedback and feed feed here. Feedback says, please will you give me feedback? Whatever that means, wherever it goes, we are leaving that entirely vague. We're just putting the mechanism to to ask for it into DKIM2. Some receivers do this today using Dkim one signatures. If you have a Dkim one signature on the mail, then you know that the person who put that Dkim one signature on saw an entire copy of the email, and therefore, the lawyers are very happy that since they've seen the mail anyway, you can give them feedback as to what you thought of the email, and no privacy issues arise because they've already seen the mail. And the notion is this is trying to slightly formalize what is going on in the Deakim one world for some people. Feed here was added to a slightly later stage as we did develop this because if you are a privacy pervert preserving forwarder, which is a concept which you can which DKIM2 will will support and that you can forward mail. And if it bounces, you don't have to tell the sender who you've forwarded it to because the bounces come back through you, because that is the d k m two way, and therefore, you can strip out all information about who you sent it on to. But, of course, feedback goes straight back to the person asking for the feedback. So what feed here says is that if you have feedback for somebody earlier than me, give it to me, and I will pass it on. Again, this is not contentious, but equally, it's undefined, and nobody's implemented anything. So that's possibly why it's uncontentious, But we think that's enough flags for that. Okay. Next flag is do not explode. It says, please do not explode this mail. It's only a request. However, is it becoming apparent from various conversations that many sensible configurations which exist in the world today will take no notice of this because they have to explode the mail to some sort of mailing list. And if their mail went off to a system that was detecting multiple copies, then this would cause a blocking of this basically good mail flow. So the current rec the recommendation from me and from several other people in this call now is that we drop this. It's not gonna work, so we should not attempt to do it. Forget we ever suggested it. Final slide of this section, I'm trying to go as fast as possible, is do not modify. This is again a request. It says, do not modify this mail, by which I mean, do not do anything which will require a recipe to describe what you have done to it. It's only a request, and it's stupidly easy to comply with, because you just don't do anything to the mail as you forward it on to somebody. If you don't wish to do that because you're absolutely, my lawyer says I have to change this mail, then you can reject it and say, do not give me mail which I cannot modify because I have to modify it if you think I'm if I'm going to accept it. So don't give it to me. Now we can write this up a bit more clearly than the current spec as to what you should do and why that would happen. Now some people, on this call, would argue that a sender cannot know when their request is unwise, and it is problematic if somebody does may modify a mail because they have really good reasons for doing it. And then they forward it because they're gonna get blamed for this because people can look at the recipes and the flags and say, but you were told not to modify it. You did so anyway. What should I do now? I hate you. So there is no consensus on the mailing list at present about this. Some people think that we should drop this. Some people say, actually, this looks really, really useful. And if you don't if you insist on modifying the mail, then just reject it and say, I'm terribly sorry. I have to modify mail. So either take the flag off or find some other way of sending it. And, basically, any discussion, I think, should be concentrating on this slide because I don't think the other ones are contentious unless people wish to try and resurrect do not explode.
[01:13:33] Murray Kucherawy: Anyone discussion on any of these? Allen.
[01:13:42] Allen Robinson: I agree. The the first three slides, I I have I have no notes. They they seem perfectly reasonable. Do not modify, I think, is maybe useful in conjunction with the stuff we talked about at the start of the meeting. If I say don't modify this message, what I'm saying is don't make changes to the message. I think it would be fair to say don't make changes to the message unless you're also going to rewrite the from field. And then if you're an entity that rewrites the from field and makes changes, well, that's now your message. And, yeah, you could just delete the the Deacon two chain entirely, but that, you know, that feels bad. Right? Like, the the it's pretty clear what has happened because everybody involved has declared exactly what has happened. Nobody's trying to pass content off as somebody else's content. The the, you know, the the original contents from field isn't like, the identity in there isn't being used or, like, put beside this content that didn't come from them. So I think I think the flag has has value in that in that it's a signal to modifying systems that if you're going to make changes, you must also change the from field. I don't think it works at scale to say, if I'm gonna make a change, but it says don't change, then my only recourse is to reject. Systems aren't gonna know that I'm doing that unless I'm a large system. And and, like, users aren't gonna be happy or even necessarily know that this is happening to their mail. I think that's it for me, Tobias.
[01:15:34] Murray Kucherawy: Okay. Tobias.
[01:15:36] Tobias Herkula: So I I will bring my real world example to the table here, but I I already had, like, some example into mail onto list. I have a bunch of business users that have exactly the situation. They they have, like, a bunch of domains. For every domain, they have an email address or mailbox that has something like billing or invoices at domain. And then all of them, they have a subject tagging modifier that says, this is a mail that came into the following company's domain. And afterwards, they have a forward to themselves, to their central holding company, and most likely to the, I don't know, external invoice handling service companies that is hosted at Google. And now I have the problem that if the invoice comes in with do not modify, which is most likely very likely thing that will happen if do not modify exists, that invoices will have this kind of flak, then the external service partner that is hosting his mail on Google Workplace will most likely reject all of that because Google sees that I modified the subject, and I can't forward it to that provider anymore. And my customer will complain to me. They will not complain to Google. They will not complain to the people who sent the invoice. They will complain to me. And I then need to reject the invoices before I even get them because I already know that I need to modify them, and the customer will complain against to me. And I don't think that makes any sense at all because it's a totally legit setup that the company has a subject tagging mechanism to figure out, oh, this is a invoice that came into company a or my company a, and this is the invoice that came into my company b on that mailbox. And then getting all these invoices into central mailbox at the holding company and all and also do a copy forward to the bookkeeper that is hosted at Microsoft or something like that. I I know it it could be that this kind of feature does not survive, but we try to disable subject tagging for, like, five years now, and our business customers refuse to accept that.
[01:18:09] Richard Clayton: So
[01:18:14] Tobias Herkula: oh, it failed, Allen. It failed.
[01:18:20] Allen Robinson: Okay. So why are we building for something that doesn't work today?
[01:18:23] Tobias Herkula: No. It works. It fails in the sense that the customer needs to then tell his bookkeeper to do white listing and all this kind of shit And all that that's exactly the forward scenario that fails constantly right now that we want to solve with DKIM2, that changes can survive forwards.
[01:18:48] Murray Kucherawy: And let's go to Brian. Yeah. I really want to can everyone hear me? Good to hear. Yep. Okay. I I I really agree with Tobias and his point here that, any requests, established by a sender trying to instruct a receiver to take some kind of action is inherently going to get ignored frequently. It's going to devalue the, experience of the sender. The sender is going to over aggressively set this flag as I don't really see a lot of capabilities that exist in today's ecosystem that allow per message, DKIM signature modifications where this flag would be set on the appropriate subset of messages in a way that would actually benefit the end receivers. So in my raw assumptions, I I would kinda surmise that the actual experience is going to be the this gets set significantly over aggressively and therefore generally gets ignored and therefore loses all value in in the long run. So I I get that in theory, specifying some kind of flag of do not modify might be helpful in some cases. But in a real world implementation, I just see so much trouble with this actually being successful and resulting in what is kind of being outlined as the desired, case in the spec. Bron.
[01:20:32] Bron Gondwana: Yeah. I've I've read a lot of this in the chat already, but the specific point that I really want to come back to here is the main value of DKIM2 is taking things which used to exist in a gray area where both legitimate email and dodgy bad behavior spammers could coexist, and it was really hard to distinguish between them. And what we wanna do is reduce the size of that gray area. So the things that are in the not sure are either clearly good or clearly bad, and so you can discriminate on them very easily. And so anything that leaves a larger gray area, I think, is a mistake. And, unfortunately, allowing people to to change the subject on messages that otherwise have very important sure. You're only changing the good stuff, but then you have to decide what what's good and what's bad in the changes, and that's much messier than not making changes at all. And so I want to try and not reopen the gray area because, well, I'm a good guy.
[01:21:38] Murray Kucherawy: Of course, you are. Hey, Wei. Go ahead.
[01:21:41] Wei Chuang: Hey. So I think there's value in this cycle because, yes, it could be misused. I think there's some risk that, you know but it does have value in signaling that this is going to be some sort of sensitive message that should not, be modified. And I think for the cases of enterprises, I mean, we already are thinking about basically having this notion of an enterprise type override mechanism because of the trust me bits and so forth. So it's likely already going to be the case that we have to do this sort of allow listing or whatever for, this type of traffic because there are enterprises that are just going to do whatever they need to do to make sure the mail gets through. I think having some way at the Deakim2 signature level to sort of distinguish these sensitive messages from other messages, I think, is valuable. So that's my main point.
[01:22:51] Murray Kucherawy: Tobias, go ahead.
[01:22:54] Tobias Herkula: So so I'm I I'm fine with going that route. I I will most likely be implementing it in a way that says, like, there's a do not modify, then the customer wish in of modification would simply not 100. So that that's I'm I'm fine with I still think that these kind of policy flex or flex that say something about how to handle a message do not belong into the spec of the DKIM2 protocol, but most likely would be more interesting in having a separate document that does this kind of policy request or send up policy requests. It could be DMARC NG or DMARC BIS in essentially a way that that's the rest that d mic now does, or it could be a new header or something like that. But I don't believe it belongs to the DKIM2 spec.
[01:23:51] Richard Clayton: Yeah. If if you argue that it doesn't go in the d q m two spec, then I think the way forward is a specific header, which which I which says, you know, do not modify colon yes. And and then that gets published as an RSC, and we see whether or not people pick it up. Or if you do that, then there's much more scope for putting more complicated things, like indicating the particular types of modification are okay, like like adding things to a subject, but modifications to the body are not allowed or something like that. So you could you could do a whole sort of algebra as to what what was a permitted modification. But but I think that but if you did that, I think you put it in a new header. You would not try and overload tags in some other system. I I think that's a perfectly good way forward. And if we take out do do not modify, I think it's beholden on the people who are speaking up and saying, well, I think it has value, that they propose that sort of header to be put in with with a much more complicated state set of statements about what sort of modifications are or not valid in order to address the use cases which you clearly have and which sound extremely legitimate.
[01:25:30] Murray Kucherawy: Wei is back in the queue.
[01:25:34] Wei Chuang: Just want to float the idea of keeping flags the way they are, but basically having a separate document just describing them as a way of threading that needle. No. You don't like that idea.
[01:25:47] Richard Clayton: Oh, that's put put it in if if if you wanna do this, put it in another header because because at least that way, get you get a much more scope for subtlety about what you put in there. And and by all means, layer it on top of DKIM2 and layer it on and observe that the DKIM2 recipes means this sort of thing is much more likely to be possible than otherwise.
[01:26:20] Murray Kucherawy: Okay. The queue is drained. Any last comments on this one? Richard, do you have what you need from the working group?
[01:26:26] Richard Clayton: I would take guidance from you and Pete as to whether or not I should leave it in in spec o seven or take it out at this point.
[01:26:37] Pete Resnick: I'm not convinced I heard consensus on this discussion so far. I mean, it sounds like there's still arm wrestling to be done.
[01:26:47] Richard Clayton: Then I I will leave it in, and I will take out do not explode because I don't think that's contentious.
[01:26:54] Pete Resnick: Yeah. I didn't hear anybody really yelping for that.
[01:26:58] Murray Kucherawy: K. And can list a discussion of this one can continue, of course, on the list. But there it sounds like I agree with Pete. We're not we don't have consensus to remove yet or change it. Thank you. Thanks, Brian. Alright. I think you wanted to talk about character sets, but I didn't see any slides for that.
[01:27:16] Richard Clayton: Are you ready to review? There there are no slides. It it occurred to me it's a late stage of that. So you can take how those slides will confuse people. Okay. Right. Hannah, who has paid more attention to the detail of DKIM2 than everybody else put together, and I wish to con offer congratulations in that direction. Pointed out some time ago a a glaring hole in DKIM2, which we all took no notice of at the time. She remembered it and flagged it up again in the last day or so, and he's absolutely correct. Basically, the problem is that if you have make a modification and you produce a red a recipe, and that recipe involves a character, which is a a sequence a character in this case is a sequence of bytes which some character set understanding system will treat as being a glyph which you can throw up on somebody's screen. That sequence of bytes may occur in a real email, but may not be valid UTF eight. And if it is not expressible as valid UTF eight, then we cannot put it into JSON as a literal string because JSON literal strings are UTF eight. The simplest way of dealing with this is in these rare cases where this character is in part of the mail which you are changing, and that part of the mail may be either in the header fields, if you're in that sort of world, or it may be in the body. If you're in that world, then and you detect that you have this sequence of bytes which you which you must not throw into something and say this is u t f eight because it would not be valid, then what you have to do is you have to put it in a separate in a recipe which is differently labeled. And the easiest way of doing this is to take your sequence of bytes, which is not expressible in UTF eight, convert it into base 64, and then put it into a recipe which is labeled slightly differently, which says decode this back into the sequence of bytes when you're doing the recipe handling. Because what you are actually holding in your hand whilst you are processing recipes against it is always going to be a sea of bytes. It is not a UTF eight string or whatever. It is it is a byte array. That is what you are actually processing when you're handling recipes. Now this is a bit tacky because we base 64 and code it twice. Once when we base 64 and code it to put it in the recipe, and then once when we base 64 and code it to put the whole of the put the whole of the recipe section into into the header field. This is a bit of a shame, but it's going to be super, super rare, but we need to do it. And I wanted to flag up that we're gonna do it, and we would just have a different type of recipe label for this. I don't think this is contentious. It's just tacky, tedious, and we should have dealt with it a year ago.
[01:30:42] Murray Kucherawy: Anyone for comments? John, go ahead.
[01:30:46] John Levine: Yeah. Hi. I agree this will work. Testing whether the contents of the line is UTF-eight is really simple. It's like it's a four state state machine. But I I also noticed Bron's comment that we might just say, like, if it's not UTF-eight, you can't sign it with DKIM2. And I'm like and well, my guess, anybody who's sending mail that's not UTF-eight is using a fairly old mail system. I think there's some I I would I have my doubts as to whether the peoples people sending that kind of mail are likely to implement Deacon too. I think it's worth it's worth asking whether whether we think anybody's actually gonna do that.
[01:31:23] Richard Clayton: Hannah thought that they were handling this sort of mail because she'd actually she had this to hand and says that they've been dealing with this sort of mail previously. So maybe it's a European thing.
[01:31:37] John Levine: Yeah. And also, I mean, I don't I don't think it's UCS 16. I think it's more likely to be, you know, antique Chinese and Japanese character encodings.
[01:31:47] Bron Gondwana: Yeah. Absolutely. It's it's probably gonna be those. The question is, should we should we make this work which adds extra complexity and double base 64 encoding and shenanigans and multiple ways that things can be represented. Japanese is certainly the the most common case of this and probably the least happy to to be told to stop using their charset. So that that might be the people to look at. I it's not a hell I want to die on, but I'd I'd rather not have the complexity unless we really actually need it.
[01:32:30] Richard Clayton: I I have nothing further to say about this. I'm I can put the the encoding into the spec o seven so that at least people can see what it looks like. We can always take it out if people say nobody will ever use that. I I don't think having two representations for the same thing is an issue. We're we're not it's there's there's more than one way of declaring other changes anyway. So
[01:33:00] Murray Kucherawy: Does anybody object with trying this on in spec o seven?
[01:33:05] Richard Clayton: Claude will take about a minute to do it.
[01:33:10] Murray Kucherawy: Remember, give him author credit. Okay. Alright. And I think our last topic is PQC, and I do believe we have slides with this. Let me get those loaded. I don't did they not go up? Wait a second. I may have to reload my client. I know I uploaded them. Hold on.
[01:33:59] Pete Resnick: I could try.
[01:34:03] Murray Kucherawy: I think Wei, I uploaded your second revision to the DMARC slides, but not this set. My apologies. Pete, if you have them handy, otherwise, I'll go find them.
[01:34:11] Pete Resnick: You should probably go find them.
[01:34:12] Murray Kucherawy: Okay.
[01:34:13] Pete Resnick: Unless you just wanna present them directly, you could try doing that.
[01:34:18] Wei Chuang: Yeah. Can I try that? I mean, I don't know if I've sent out, really the second set.
[01:34:24] Murray Kucherawy: Oh, well, then you can just talk then if you like.
[01:34:27] Pete Resnick: Yep. Go ahead and share the screen. Let me
[01:34:31] Wei Chuang: Does that work? Okay. Check.
[01:34:33] Pete Resnick: Yep. There you go.
[01:34:37] Wei Chuang: Does this work?
[01:34:39] Pete Resnick: It's going slow. Hold on. We're we're not loaded quite yet.
[01:34:42] Wei Chuang: Oh, I see. It's not much. I mean, it's it's it's hardly anything, but, I mean, I mean
[01:34:48] Pete Resnick: There you go. You're on the screen.
[01:34:50] Wei Chuang: Okay. Let's just do that. And it's just really simple. So I think the last time we talked about PTC, I think, at the last meeting, in person meeting, basically, was that we were going to go out and ask to see, you know, from folks in the ITS that are familiar with PTC on what to do for the algorithm. And I think more or less, some informal conversations happened. The advice was to go with, MLDSA, I guess, you know, one of those algorithms. And then, basically, you know, there's some I I don't recall if it's, there's actually three of those types of algorithms, and then there's, you know, a preference for either of either the smaller key sized ones or the smallest, which is 40 fours versus, say, 65. I put that out, you know, that that advice, basically, from the informal advice, out on the list. And then I think Hannah pointed out that, that she'd be much happier with the composite construction, because of some of the discussions had on the, TLS mailing list. No one else has chimed in. I guess what I was going to ask here was if anyone has a strong opinion about that. And if not, do we have a direction to work from? I mean, if Hannah's the only strong opinion, maybe we do do this composite, if that's okay with folks interested in PQC for DKIM2. So I think just to really summarize, you know, that discussion out on the QoS mailing list, basically, issue made famous by Daniel Bernstein is that PQC algorithms are fairly new, and that there may be some vulnerability that three letter agencies in The US may be able to exploit, but, you know, probably true of many advanced agencies. And, rather than, you know, leave it vulnerable or potentially vulnerable, we can create this composite construction that uses the well known, you know, elliptic curve typically. Or, basically, one of the classic algorithms that's well known, but the the one that has sort of the best, properties is basically this Edwards curve, two five five one nine. It's pretty small key size and signatures, and then it doesn't add that much overhead. And that way, a weakness in the post quantum signature algorithm does not, does not create a vulnerability, basically, because you have the backup, which is, you know, the classic, signature backing it up. I guess the question to this group is, you know and I'm sure no one wants to look silly or look like they're part of some secret cabal. You know, maybe the direction is to just for the you know, an argument for doing the composite is basically we go with the safest option. And then at some future point, when we get operational experience, like, maybe that few set like, eight bytes or whatever it is, you know, that that actually is meaningful. And then, you know, maybe we we rethink it after. If anyone deploys, we we can rethink on, like, you know, optimizing it further. Potentially, by then, because there's so many PQC algorithms, some with very much better characteristics than MLDSA, that maybe by then, it'll be mature enough that we can go with one of the better options as well. But that's that's kind of the the what this slide is about. Richard? Or sorry, John? Sorry.
[01:39:10] John Levine: Yeah. We were supposed to I mean, some months ago, we figured we were gonna ask ask an ITF expert what we should do, and the ITF expert is Paul Wouters. And I actually talked to him at the Vienna meeting a few months ago, and he never got back to us. So I think some somebody perhaps me should talk to him and see if he has any opinions that disagree with this. The problem with MLDSA 44 is actually not so much that the NSA might have deliberately weakened it, but just that cryptanalysis is really difficult, and it and there's way too many cases of an of an algorithm that looked that looked good, and then four or five years later, somebody found it, oopsie in it. Mean, like, we clipper chip is a famous example of that. So my inclination would be to say we might as well use composite because MLDSA 44 is so much bigger and fast bigger and slower than Ed25519, but the incremental cost of doing of doing the composite over doing just just DSA 44 is very small. You know? And the and the the incremental safety is is is meaningful. So, you know, I think we should check with them. And unless some unless unless they say and also with Steven Farrell. Unless somebody says we're missing something, we should just go ahead with that. And I probably should be the person to write it up unless we have a better volunteer.
[01:40:24] Wei Chuang: I agree. I I had thought someone already had asked Paul Wouters, and he said to go use MLDSA 44 or 65. I I I have to go check back, but I thought that it was already asked. And that's the reason why I Yeah.
[01:40:37] John Levine: Mean, my my recollection is when I talked to him and explained the issues. He said I think he's I think he said the same thing. Like, yeah. That seems reasonable. But yeah. But I I don't I don't recall that he ever gave us a formal answer. If he did, that's great.
[01:40:48] Wei Chuang: And I'm happy also to just go and go ask. I I just because I thought I thought the comment go by, that there was already sort of a unofficial answer. But if we want to do the official way, it it's fine too.
[01:41:01] John Levine: Yeah. And, also, I mean, to the extent we can align with what DNS op does for DNSSEC signatures, we're more likely there that it be nice if we use a similar algorithm since then it's more likely we'll we'll use the same libraries, which will be better debugged.
[01:41:25] Richard Clayton: My comment is is much the same, which is which is that we should do a composite because I do not particularly my name is on this. I do not want Dan shouting at me. It's it's it's not necessary, and the extra overhead is really small. I take John's point that going the same as is being used elsewhere in in DNS is would be a good idea. We we could change this in a fairly late stage. And for the implementer, this is just a string which you put on one line, and you call a library, and the library does everything in sight anyway. So it's not a it's not a big deal to change it at at a pretty late stage. As to who wants to author, by all means, let people volunteer to put justifications and so forth for the record on the list. But where this actually belongs is in spec o seven, and we just add it to the list of algorithms in spec o seven with appropriate references. Because if it is in a separate document, then some implementers are going to overlook it. So if we want people to actually do it from day one, which we do because if they don't do it on day one, they may never do it. Yes. Yes. That kind sounds as if it contradicts what I've just said it's easy to change. It's easy to change up to the point at which we change the RFC, and then we may not be able to change it for ten years. And our experience with with elliptic curves and Dkim-one shows us that adoption is super slow and effectively nonexistent. So this needs to be in the RFC at the point to which it's published. We can change it at all 48 if we need to, but not after that. So the right place to put it in my view is into the spec, and the right thing to do is composite so that people don't shout at us, and so it does turn out to be flaky. Because it's not gonna turn out to be super flaky, very unlikely. It's gonna turn out to be major governments can attack this, but major governments will not be able to attack the composite. So let's do that.
[01:43:49] Wei Chuang: The only thing I I agree completely there, except for one caveat, which is don't we want to also update, 6376 too? But you know?
[01:44:04] Richard Clayton: DKIM1. No. No point. Why? No. We're not interested in DKIM1 at all. Stop implementing it. Stop doing it. Implement DKIM2 because by next February, we're all gonna do it.
[01:44:20] Murray Kucherawy: I think actually touching Deakim one is probably outside of our charter, but we need to be careful there. Peter, Pete, go ahead.
[01:44:25] Pete Resnick: Okay. Well, there was, you know, an attempt by way to sort of factor out some of the crypto stuff initially, into a separate document. So putting this in there might make some much sense. But, no, I actually just raised my hand simply to say, let's not worry too much about shouting one way or the other because even the people who in the TLS working group who were being shouted at who supported these noncomposite algorithms simply wanted to publish them, and they're still marked in the TLS registry as should not use. So I think the composite is the right thing to choose. I don't think anybody in TLS would suggest, you know, otherwise from their end. And so I think when doing a signing algorithm with a composite, I think, will be noncontroversial. So we should probably just go ahead and do that.
[01:45:31] Wei Chuang: Sounds good.
[01:45:35] Pete Resnick: Richard, is that an old hand? I'm going to presume the answer is yes. And nope. There it goes.
[01:45:47] Murray Kucherawy: So, Wei, do you have what you were looking for here for next steps, or, did we resolve this?
[01:45:56] Wei Chuang: I think so. I think, there can be suggested text for zero seven, and I think
[01:46:03] Murray Kucherawy: Yeah. John said he like
[01:46:04] Wei Chuang: the direction is to just only put in the spec, which if people are fine, I guess, it's fine by me too.
[01:46:11] Murray Kucherawy: Okay. Thanks. That brings us to any other business. The only thing I wanted to ask about is another interim. Or just do people want generally to have another one of these, let's say, mid October before we get together in November? We it seems like we have a regular cadence, and I'm I imagine the answer to this is yes. Is there anybody who doesn't, or is anybody who wants to say in particular that we really should?
[01:46:41] Tobias Herkula: Pete
[01:46:42] Pete Resnick: That's Richard.
[01:46:43] Richard Clayton: Please avoid the. Oh, thank you.
[01:46:46] Pete Resnick: That's right.
[01:46:47] Murray Kucherawy: Yeah. We can go before that. That shouldn't be a problem. Anyone else? I'll assume yes, and we can always cancel it. But we have to meet certain announcement requirements, which the clock is ticking on those. So we'll pick a date probably the week before the one that Alex just pasted in there and put it together. Wednesday, same day same day of the week and same time. Please comment or say something at the mic or email the list if you want something different. Any other business that anyone wants to bring up while we have, let's see, eleven minutes to go? Oh, I'm sorry. Bron sent some slides in. You were right. And debug, take it away. Here they come.
[01:47:33] Bron Gondwana: Thank you. Sweet. So these are two little things that I promised I would write up. They're both drafts now in the data tracker as personal drafts. Authres, the authentication results head of field was, written by, someone who was very lucky to get RFC eighty six zero one, which is not confusing at all when you're doing time related stuff. It is specific to the local system. Authentication results can be stripped and certainly shouldn't be trusted if written by anyone else, but it's still useful to have a standard definition of what to put in there. The draft test artifacts like do not explode in there, so it certainly needs some work. But I I suggest that we should specify what should be in authentication results for Deakim two, whether it's part of spec or whether it's a separate document is a question I have for this group. So I'd love feedback on that. It looks something like this. Here is part of an authentication results for a mail I had that passed and it says that this is the one that signed for I equals two, came from dkim2.com as the last hop, and here's one that failed, where it got something that came not signed. So they just look like that. Dkim two equals Anna code, and the rest is the spec. Tobias.
[01:49:07] Tobias Herkula: So I'm all in with having the outdress thingy, but I'm also all in in having a separate document for that that is essentially updating the the existing chain of outdress of these.
[01:49:18] Bron Gondwana: Yep. Alright.
[01:49:22] Pete Resnick: And Just a question, Bron. The the authorized thing does not have a registry that we can just add to. It would have to be an update to the document?
[01:49:37] Bron Gondwana: You need to find how it works somewhere. You can't just you can't just name it. You need to give a little bit of what the fields are and stuff. So that's the link there in the chat.
[01:49:54] Richard Clayton: I I I think it should be a separate document which supersedes all the previous ones. It's bad enough at the moment when you add when you do a search for authentication results, you put an RFC in, and then the next thing tells you, no. It's replaced by this one. And you try again, and it says, no. It's replaced by this one, and you go on for about three or four. So adding another one to that chain seems the right thing to do rather than make people look at more than one document in parallel.
[01:50:23] Bron Gondwana: Murray is the author of the original one.
[01:50:26] Murray Kucherawy: I think this I think Pete might be right that this is entirely doable by registrations rather than updating 8601. You can update registrations. But I agree you still need a document to describe all the fields you're adding. So but I'm happy to work with you on this.
[01:50:42] Bron Gondwana: Yep. Cool. I guess, in that case, if it's going to be a standalone document, then I'm asking for adoption on it.
[01:50:56] Richard Clayton: I just took
[01:50:57] Pete Resnick: a look and there's nothing in the charter that would prevent us from doing this, so it's fine with with me.
[01:51:03] Murray Kucherawy: Yep. We can do a call for adoption on the list.
[01:51:07] Wei Chuang: Cool.
[01:51:08] Bron Gondwana: The second one is the x dkim two info header field. I also wrote a document about that. It's basically just helpful debug information to be used during this experimental phase. I suggest that people use it while they're building their experimental draft spec based implementations so that we can look at that and see which version of the spec they were using when they wrote the header and also see which header fields they looked at when they're creating a message instance, which helps see if there if there's some skew in the fields that they're including or not including. It looks something like this. Sorry about the small text. Here's an example case where it was my mailman implementation that was stamping as couple of things, and then the the milter checked
[01:52:05] Richard Clayton: it
[01:52:05] Bron Gondwana: and verified an incoming message instance and signature first, and then the mailman changed the message and created a new I didn't include the message instance in here because it made the text way too small, but it created a new message instance. And then here's another example of something that was created from fast mail's implementation, which is hopefully gonna be launched next week. If everything goes smoothly, there's some pieces I need to get in place first because we use fast mail dash internally and strip it at the edge, and the choice was either to just ignore that in our signatures or change our names so we are renaming our headers. That's all I've got for that. I just wanted to to bring awareness and show some examples of it. But please, if you're implementing Deakim two, add one of these headers and then I can understand what you did.
[01:53:00] Murray Kucherawy: Questions or feedback? Okay. Thanks for the thanks, Bron, for that. We'll do a CFA on the first one and do nothing about the second one for now. That's the end of our agenda. We have five minutes to spare. I guess we have an action item that I'll take relatively soon both for that CFA and for scheduling an interim in October before MOG. Is there any reason to do it after MOG? Avoiding doesn't necessarily mean going before, although that seems to make sense.
[01:53:36] Pete Resnick: Then we're getting awfully close to San Francisco, and then Yeah. You're right. Already into November.
[01:53:40] Murray Kucherawy: Okay. We'll do it. We'll do it before. Yeah. I have nothing further for today. Thanks for everybody. Peter? Anything, Pete, I should say?
[01:53:49] Pete Resnick: You can be my mother and use my phone.
[01:53:52] Richard Clayton: Totally understand.
[01:53:53] Pete Resnick: Nothing from me.
[01:53:54] Murray Kucherawy: Okay. Then thank you, everybody. We'll get the minutes out, much earlier than we usually do this time. And thanks for coming, and watch for the interim.
[01:54:07] Pete Resnick: Oh, and John says that the week before, is
[01:54:13] Murray Kucherawy: It's not IHF is not in Bali.
[01:54:14] Pete Resnick: I I can in Bali.
[01:54:15] Murray Kucherawy: That's not funny.
[01:54:17] Pete Resnick: Yeah. Although right. Which would put us just in we'll discuss what what's gonna be possible here. And I understand what the issue is because we may not have enough time to get an announcement and do something about it then.
[01:54:35] Murray Kucherawy: Yeah. We are required to give I think it's at least two weeks notice for an interim. If we do that if I issue that today, we're looking at maybe October 12 or so or whatever the Wednesday is of that week. I think that might have and that might be that might avoid a MOG, and it certainly will avoid or sorry. It might avoid ICANN and MOG, but it we not enough can happen between now and then.
[01:54:59] Pete Resnick: Right.
[01:55:02] Murray Kucherawy: Why don't we just set it, and we can always we'll set it for the week of of of iCan, and we'll just cancel it if it seems like that's not a good idea.
[01:55:09] Pete Resnick: Yep. And, you know, I mean, you you can always put yourself on the screen, you know, with the beach in front of you and and make fun of the rest of us.
[01:55:18] Murray Kucherawy: So That's very true.
[01:55:21] Pete Resnick: Alright. Cheers all.
[01:55:23] Murray Kucherawy: Thank you, everybody.