IETF Meeting Minutes

Session Date/Time: 17 Jun 2026 20:00

Pete Resnick: Looks like people are floating in slowly. We'll give a few minutes, particularly for my co-chair, who just showed up. Yay!

Kind of hoping Igor or Tobias shows up or someone who is willing to talk about Tobias's new proposal to address ways issue with multi-domain signing.

John Levine: I know Richard has been thinking about it, perhaps you could tap him.

Pete Resnick: I'd be happy to. And there are some slides which have been approved which will help me explain.

Pete Resnick: Excellent. Excellent.

Give a minute or two more, although we can easily just start going through the easy slides first.

John Levine: We know who gets all the agenda items if they don't show up.

Pete Resnick: Yeah, exactly.

All right, well let's at least get started with the administrivia. Um, so welcome to our third and final interim before Vienna rolls around. You are reminded that this is an IETF meeting, therefore you must agree to the IETF policies on intellectual property and behavior.

You also must accept the IETF Code of Conduct.

The Note Well applies to all of our meetings.

And the few meeting tips. Um, everybody is signing in with the data tracker already. Um, please keep your audio and video off um, until you are presenting or talking. Um, if you have a headset, that is useful to stop feedback.

We'll give a minute or two more, although we can easily just start going through the easy slides first.

We have a queue of four here if you have but two of you are visible to me right now and I'm not sure you're still in okay they're going to hand up.

Okay. Wei, anything further?

Wei Chuang: Yeah, so um, one thing that I'd just like to bring up for other business was basically around um, algorithms and in particular, uh, post-quantum algorithms for signing, um, and if there is appetite in the working group for looking at um, post-quantum cryptography algorithms for signing, um, and whether it would be the reason for that basically is in this process of um, uh, the DKIM2 has this uh, capability to sign for multiple algorithms, and in fact is strongly if not required to do so. The question was whether this is a good time to start thinking about doing post-quantum for that second algorithm, um, because, uh, it is something that probably heard, you know, our company, uh, Google thinks that is going to happen a lot sooner than expected, and then that it would be a good idea to try to get uh, something ready for DKIM as well as DKIM2 sooner rather than later. And there's a long road, I mean, of course, there's a lot of work going on in the other parts of the IETF, uh, and, uh, it's not even entirely clear what sort of the best algorithm out there, uh, and so there would be still basically saying that there's still a long road to try to get something for DKIM for post-quantum. Um, but, you know, the the question I'm posing is can we get started now? Would the working group have appetite to go do that?

John Levine: Richard, go ahead.

Richard Clayton: I don't think anybody in the working group has any expertise as to which post-quantum algorithm we should pick. Um, and so maybe an AD, is should be, uh, approached in order to ask, uh, basically, who should we ask to tell us what to do? Um, and I would certainly echo, uh, that though I, uh, I don't believe that the laws of physics are going to let us build these things, but that's my personal opinion. Um, um, I do think that if we want, uh, any particularly large adoption and people rolling it into standard code bases, then I think it's, it would be, uh, very wise of us to actually have the post-quantum, uh, algorithm chosen and specified and so forth at the point of which we finish the document because I think that is the best chance of getting widespread adoption. As people know, there is not widespread adoption of, uh, elliptic curve, uh, for DKIM1, even though it's been specified for some time, because it was basically too late to the party and nobody could see why you needed it. Since we think, since the people who, uh, believe in magic, uh, believe that the post-quantum is needed, then I think that, um, we, we, we should get on. Though working groups would say we picked one. In fact, we'll be told which one to pick, by people who have some clue about these things.

Murray Kucherawy: Andy? Oh sorry, John was next. My mistake.

John Levine: That's okay.

Um, what we have done so far is essentially we we have adopted, um, algorithms that, that, that TLS has chosen. And for anybody who hasn't been paying attention, there is a, there's a, there's a, there's a, there's a DNSSEC efficiency hack that turns the NXDOMAIN into a no data. So it's not, you don't get an NXDOMAIN anymore. Now, to now to fix that they invented a pseudo-RR type called NXNAME, which a, which a, which a resolver is supposed to say, oh, I see an NXNAME and then it turns that back into, it turns that back into the, turns that back into the, into the correct NXDOMAIN to return to the client. So in theory, if people fully implemented 9824, the NXDOMAINs would look fine. The problem is that that in fact, that, that, in fact, while there are authoritative, there are definitely, um, DNS providers doing black lies, notably Cloudflare. The, the NXDOMAIN recovery, um, um, is not widespread. And I had a, a surreal discussion on the, on the, on the DNSOP list saying this is terrible, like if if you if you turn,

Pete Resnick: Can I pause you for a second, John? Are we talking about the same erratum?

John Levine: I think so. Isn't this the one that says check for NXNAME if you, if rather, when you're looking for NXDOMAIN?

Murray Kucherawy: Oh, no.

Pete Resnick: No.

John Levine: Oh, never mind.

Pete Resnick: I'll take, I will take this one then. Um, this one has to do with some ABNF around the way you construct the data hash, uh, in the, in the original 6376. It appears correct to me, so I was just going to bounce off the working group that I intend to accept this one and, um, uh, unless there's some reason not to. It seems like it, it coincides with a previously approved one, this is just a second edit of the same nature.

Um, the data hash, in particular, the data hash does not contain the body hash, that's done differently.

Anybody want to, uh, does anybody disagree with, let me put it this way, does anybody want to stop me from accepting that erratum? Or telling Andy to, anyway.

Okay. Okay, um, I will relay that message on the list to Andy and, uh, that'll be the end of this one. Um, John, Working Group is down the hall and to the right.

John Levine: Um, thank you for, thank you for your, your, your, your, your kind of ignoring the fact that, that, that I'm a confused old geezer, please continue.

Pete Resnick: Right there with you, John.

Murray Kucherawy: Oh, I see you've come here for an argument.

Pete Resnick: All right, um, so hearing no objections to Murray telling Andy what he just heard in this room, that he is going to send you an email that says, uh, to accept the erratum, uh, we'll move on.

Um, I see that Wei is here. Let me, um, uh, hide these slides for a moment. Um, and Richard prepared a slide on, uh, the discussion I'm told you, you all had about, um, uh, Tobias's proposal to address the multi-domain issue, uh, in, uh, where was WG last week? I don't even remember. Um, I wasn't there.

John Levine: Montreal.

Pete Resnick: Montreal. Um, so let me pull up a slide, uh, to share a slide. There's what Richard had to share. Which one is it? Oh, imaginary hops, right here.

Um, so, uh, why don't, uh, Richard, uh, Wei, why don't you talk to this while you're both here, and tell us what, what this is all about.

Richard Clayton: Okay, I'll, I'll start because I know what's on these slides, uh, and Wei can, uh, chip in.

Right, so the issue, the basic issue is that when you have some sort of automatic forwarding, then you have to pay attention to the chain of custody. Uh, because DKIM2 insists on a chain of custody, uh, right from the moment the email is created till the point at which it is finally delivered.

Uh, and so as a mailbox provider, uh, such as the one that Wei runs, uh, then you may well receive an email which comes in as, which is addressed to, uh, some sort of vanity domain, uh, and it is then going to be forwarded, uh, as the, uh, with the identity, with a generic identity of the, uh, of the mailbox provider. Uh, perhaps to yet another mailbox provider, who knows.

Uh, so you have to show that there is a chain of custody between those, and it wasn't just, uh, some, uh, some, uh, sort of, uh, teleportation between the two. So you need something that shows that, uh, example.com really did forward in some sense to, uh, the mailbox provider, who then sent it on its way. Now, uh, is not really, uh, a hop because it's almost certainly as the, as the mail turns up, it is looked at and then, um, it may well go into a mailbox, but it will certainly get pushed on without any, in a completely automatic way.

Uh, also, ESPs have the same problem, which is that the ESPs, uh, who are acting on behalf of a brand creating mail, uh, containing fine marketing messages, uh, uh, always double sign. What they do is they, uh, sign as the, as the brand name because they need an aligned DKIM signature for DMARC to work, uh, and then they sign as themselves, uh, to show that they are handling the mail and because, uh, that second signature, uh, gives a, basically gives people a nice warm and fuzzy feeling that it's gone through the ESP, uh, and there may be feedback associated with it as well.

So, uh, in that case as well, there has to be something which shows that the email was forwarded in some sense from the, uh, brand name to the, uh, to the ESP, but of course it was never forwarded at all, is all entirely imaginary because, uh, the ESP creates the email, uh, out of, uh, out of raw electrons, uh, creates the email, uh, and then puts in two signatures and sends it off.

Uh, so, there's two ways you can do this. You can either invent an email address for the hop, or provide, uh, some sort of syntax, uh, for this. Um, and Wei produced a scheme, uh, which, uh, several of us looked at and said we thought was a bit complicated. Uh, so I said you could do exactly the same thing, uh, just by leaving out the local part of email addresses, uh, and Tobias came up with a rather more elegant solution, which is, uh, what's going to be on the next slide.

Uh, do I press buttons for next slide? Uh, lost my buttons. Okay, yes, um,

Pete Resnick: I did it.

Richard Clayton: All right, thank you very much. Um, the, uh, and basically, Tobias in fact made two suggestion, a combined suggestion, one of which was the forward, which is what I'm describing here, and one of which is backwards, which after a lot of, uh, head-scratching and a certain amount of drinking of beer, uh, we're now all convinced, uh, is not necessary and it fixes a problem which nobody has. Uh, so let's ignore the second half of what Tobias, uh, suggested and just go with the first half. And essentially, the first signature that you put on, and I've got the ESP example here, uh, but the, uh, mailbox provider doing forwarding is, is, is, uh, essentially the same. It's just not at one and two, it's a higher numbered, uh, settings. Uh, then the, uh, the first DKIM2 signature, uh, has, uh, is signed by example.com, which is the, uh, the brand name, uh, and, uh, it says, uh, that the mail is coming from Alice at the, at the brand, and the receipt to is the actual real receipt to of the message, at the, at um, Google or Yahoo or, uh, wherever it may be, suitable flags for whatever, uh, flags the, uh, brand wishes to put on the, uh, message, uh, and then it says next D, um, now we may shorten that down to, uh, we will shorten that down to something else, uh, but this is, uh, for clarity here, it says and the next signature will be from esp.tld, the ESP. And then the next signature is indeed from, uh, the ESP, uh, and it says what the mail from and the receipt to will be for the, for the real SMTP conversation whereby, where the ESP is going to send it out, to the mailbox provider, uh, but, uh, if you notice, the, uh, uh, basically, there is not alignment between the mail from receipt to because there's a, because it went magically went from the mailbox provider to the ESP, uh, sorry, sorry, went magically went from the brand name to the ESP, uh, but that's okay because the brand name said that was going to happen, uh, with that next D, uh, uh, tag in there.

Now, obviously, i=1 has to be signed by example.com to show that this is a valid, uh, the, the next, the next voice you hear will be, uh, and, uh, so that must be signed like that and in the standard way, which, how the whole world works, uh, at scale today, uh, the, the easiest thing is the ESP applies both signatures, uh, and, uh, tells the brand name to put a CNAME into their, uh, for their key record, uh, so that, um, all of the key material and so forth is sitting at the ESP the whole time, uh, but, uh, when we need the key material, we go and look at the d=example.com, we then follow the CNAME and then we get the key material we want.

Uh, so, if you want, you can transfer the key material around. It's irrelevant to this. Uh, and, and basically, the receiver just checks, uh, i=2 without having to worry about, uh, the earlier one. It's only when, uh, the receiver starts thinking about, is the chain of custody okay, uh, that anything interest, that, um, uh, is going to take any notice of the next D. So the, the, the very fast, uh, path, uh, let us, uh, check things, uh, for the, uh, for the receiver is unaffected by this. It's only when you start looking at the chain of custody that you see the next D and so forth. And, basically, this avoids inventing an imaginary address at the ESP, which, uh, the mail was sent to in order to show a chain of custody because that, that just never happened, and inventing such an email address will just confuse everybody.

So, Bron, you want to jump in here?

Bron Gondwana: Yeah, I put my hand up because there's a thing on that slide which I disagree with. That receipt to from i=1, I think is left over from the, when the RT wasn't included in i=2. Um, the receiver doesn't, doesn't look at i=1 at all. It doesn't look back through the hops. It just looks at i=2 and looks at the RT from that to tell that it's for itself. The fact that it happens to be the same on i=1 is irrelevant to that receiver.

Richard Clayton: We can certainly take that out, that RT on i=1, it isn't doing anything. It was more for clarity, um, but, but it isn't doing anything.

Pete Resnick: And Wei, if you want to jump in here, uh, I mean, or Bron, please continue, but, um, you know, I want to hear whether this, you know, addresses you and others who, uh, were having this issue in the first place. So Bron, go ahead.

Bron Gondwana: Yeah, I just wanted to say the important fact is that we should never make the receiver of the message have to look at anything other than the top DKIM2 signature to determine whether it's correct or not. Um, and so that means just checking that that signature is signed correctly with a, with a from address that it can bounce things back to that aligns with the from address's domain, and all those factors are present in here. So, the, yeah, this other thing doesn't affect the receiver at all, apart from the eventual checking that the whole chain's valid.

Pete Resnick: Go ahead, Wei. I put myself in the queue for a question.

Wei Chuang: Sounds good. Uh, yes, this does cover, uh, my, my earlier suggestion and covers, resolves my concerns. Um, I think, yes, we will see other instances where we may need, uh, multiple signatures in one ADMD. Uh, certainly is an enterprise issue. I think there's other places where like for feedback or for other things, uh, that this will become a more common place pattern, uh, especially like beyond just, you know, that's already happening in the ESP space, but I think other places will, uh, want to show relationships and this is a way of doing that type of thing.

Pete Resnick: Cool, um, and the reason I put myself in the queue, um, was to ask Bron, so imagine that this appears sort of in the middle of the chain, because someone wants to do something goofy. I always come up with the, you know, the worst possible scenario.

You would look at the, um, you would go through all of the i=s back as you unwind to make sure that any changes were legitimate. It's just that when you do the bounce, you only get to what in this example is i=2, correct?

Bron Gondwana: Yes. Yeah, you don't need to, you don't need to look back in order to determine whether you should receive this message or not. So that should only require you to check the top one and that it is, it, um, validates correctly for just itself and, and the headers that are mentioned.

Pete Resnick: Right, I mean what you're saying is you don't need to go one more back. Or, you, you will see it and you will say, oh, this is, I don't need to check it again because it's the same damn thing.

Bron Gondwana: Yeah, well what you'll, what you'll see is do is look at it and say, yes, this is validly for me and yes, this is validly signed by esp.tld, the ESP. And so that's why you check the RT equals from i=2. To check the RT equals from i=1 instead would be completely bogus. You'd have to look at that first one and then go look back and see if the previous record had a next D, in which case you look for the RT equals on there instead. That's silly. You should be looking at the RT equals on the topmost one, which, it's been put there now. In the first draft of this it wasn't there and you had to do that look back and that was just overly complex, for no benefit, because you can put it wherever you want. You, you are the person creating both of these signatures, so you can put it in the right place.

Pete Resnick: All right, Brian, you're up.

Brian Godiksen: Yeah, I just wanted to know um, a few things here. One, I I do really like uh, this outcome, um, specifically what I appreciate is being able to see the, uh, actual destination recipient to um, intended by the, um, you know, i=1, the initial d=domain signing, like that this is the intended recipient. So I really like seeing that.

My question, which I, uh, have for the group would be is, can next D, um, be present on signatures? So, I get that theoretically you could have it twice within a chain at different places, but could you theoretically, um, have, uh, two in a row? So could you have i=1, uh, you know, with the next D and then i=2 with the next D and then basically a third signature? Could this be extended or is this going to be limited to just um, one, uh, pair of domains, uh, represented within the ADMD?

Richard Clayton: I, I believe that it is extendable and there's no problem with it being extended.

Brian Godiksen: Awesome.

Pete Resnick: Allen, go ahead.

Allen Robinson: Uh, yeah, on that, like, conceptually I view this, the, next D as kind of being an override for what used to be the, or what I guess still is, the default stance, which is that the next signing domain should be the domain of the previous hop's RT equals. So, there's no reason to say that this can only be a pair of them. It's, it's just saying like the when you're looking at the chain forward, or backward I guess, it, like, that's, that's where you get the domain from is the next D instead of RT.

Pete Resnick: And, you know, I know a lot of folks were, you know, uh, have not seen this yet because this was at least so far, um, it sounds to me like, uh, cocktail napkin drawings last week. Um,

Richard Clayton: It was Tobias the week before on the list.

Wei Chuang: Yeah, this, this was on the, the list.

Pete Resnick: Oh, was it on the main list? Okay, tells you how well I'm keeping up. Um, but I guess, um, you know, the only thing I heard, um, uh, by way of objection right now is, and I don't even know if it's an objection, is Bron saying that the RT equals on the i=1 here is superfluous because next D is telling you ignore RT in this case. Um, are there any other objections or should Richard just take a stab at putting this in the document in the next version and we'll get to see it in, uh, Vienna and work on it? Or just say, wow, that looks perfect, let's move on.

Richard Clayton: I will check that there's nothing bad about removing the, the first RT, uh, since I'm always in favor of simplification.

Pete Resnick: Yep.

Bron?

Bron Gondwana: For what it's worth, I don't mind it being there, um, just that it can't be the one that you look at.

Pete Resnick: Right. It, it's, it's simply superfluous.

Bron Gondwana: Yeah. Yep.

Richard Clayton: We, we don't like superfluous, because if it said some, if it said aardvarks there, then they'd have to remove it. Right.

Pete Resnick: Right, try, try and come up with ways to leave people without foot guns, as they say.

Um, okay.

Good. Um, I, I like lack of screaming and yelling. Fine thing.

All right, um, then the next thing on our agenda,

Richard Clayton: And, and just to be clear, just to be clear, Pete, um, if you don't want to use this syntax, you don't have to.

Pete Resnick: Right. Right. You can make it like a real fake hop. That is, it can look like a real hop, and, and you move right along. But if you want to say, yeah, yeah, yeah, just ignore RT, you have this mechanism to do it and sign it internally.

A simplification.

Good.

Um, so all other business was on our hit parade, I, I believe, oh, Trent? Sorry, missed you.

Trent Adams: Yeah, sorry, I raised my hand and I didn't want to jump in, but it sounded like you were about to move on.

No, not to ask a stupid question, but I'm going to do it anyway.

If we're going to include the next D, and that's the override, why isn't that just what we do anyway? Why have the receipt to field at all? Why not always just put next domain equals?

Richard Clayton: Because you don't know what it will be because the, uh, the domain matching algorithm and the, uh, is, is fuzzy and the mail from receipt to is not fuzzy at all.

Pete Resnick: Yeah, Allen, go ahead.

Trent Adams: Fair enough, just wanted to bring it up.

Pete Resnick: Okay.

Allen Robinson: Well, also, for anti-replay, we want to assert that the RT value in the signature is equal to the receipt to command in the current SMTP transaction.

So you, you have to have RT equals for that, at least for the topmost one. And you can't remove it from any previous ones because then you break the signature. We, we could add next D to every signature, that, that could also be...

Pete Resnick: Oh, that again gets superfluous in the normal case because it better the heck match the RT, right?

Allen Robinson: Um, yeah, you, you would have the same type of alignment expectations, but you wouldn't have to parse the address to figure out what's supposed to be there.

Richard Clayton: The fuzziness is the issue here.

Allen Robinson: So, yeah, I, I don't think it's worth having it, but we could.

Pete Resnick: Bron, you want to make an argument one way or the other?

Bron Gondwana: Yeah, specifically to answer Trent's question explicitly, the purpose of next D is to say the next domain is me as well, I, this is a trust relationship between these two domains. And the purpose of all the other relationships is this is not a trust relationship between these two domains, I'm sending this across the internet to someone I don't know anything about other than that they have this receipt to email address. So they're two distinct cases, and we don't really want to conflate them. If you see next D, that should be, this is me signing again, or this is someone I trust signing again, and, and we have a relationship.

Richard Clayton: Potentially you can hang reputation of the pair of d= and next D. Nothing to do with, nothing to do with the specification, but you can, but it is one place that you can hang reputation.

Pete Resnick: All right, then moving right along, um, your next slide is, was your first thing for all other business, right Richard?

Richard Clayton: Correct.

Pete Resnick: All right. There's your next slide. Please ask the working group what you will.

Richard Clayton: Right. Okay.

Um, let us suppose you have an email which, uh, comes through you, uh, and then you send it on to somebody else, and they send it on to somebody else, and they send it back to you. And it goes, so it's going round in a bit of a circle, not necessarily a true circle, but to, uh, multiple places on your domain, uh, but possibly the, but possibly the same one. Uh, and then you decide to, and somebody decides to generate a bounce message. Um, it may be very complicated for you to work out whether or not it is being bounced back to you, uh, from hop 7 or from hop, or from hop 4. Uh, and, uh, what you do with the mail might be different depending on who it's been bounced back from. Uh, and, what you concluded about the bounce would be, uh, simpler. So, the simplest thing in order to fix this, is to say that when you get a, uh, a DSN given to you, uh, and you are deciding that you are going to pass that DSN back along the chain to the person, uh, who gave you the mail in the first place, then if you strip out of part 3 of the DSN, the headers which you have, the modifications which you have made to the message, uh, and then generate the DSN, uh, as if it, you had never forwarded it to anybody else at all, this is kind of a good thing from a privacy point of view, and it's a spectacularly good thing in terms of complexity as to worrying about whether or not the mail is coming back, uh, through multiple hops and which hop, uh, you, if you appear at multiple places in the, uh, in the chain of signatures, uh, then which of these are you meant to be dealing with just at the moment. So, the, the very fast, uh, path, uh, let us, uh, check things, uh, for the, uh, for the receiver is unaffected by this. It's only when you start looking at the chain of custody that you see the next D and so forth. And, basically, this avoids inventing an imaginary address at the ESP, which, uh, the mail was sent to in order to show a chain of custody because that, that just never happened, and inventing such an email address will just confuse everybody.

Now, of course, uh, there's a side effect of this, which is that if people have managed to mangle the headers and use null headers in such a way that, uh, somebody on the chain cannot generate the previous version of the message, uh, then that is a somewhat of a problem. But having thought about this, we, uh, at, well, I and the people I've talked to about this, cannot think of any reason why anybody needs the, "I have done things to the header but I'm not going to tell you what it was." Now, we know that people need this for bodies for all sorts of operational reasons and so forth, and, and, the spec deals with this and so forth. But DSNs do not need to contain body fields, they only need to contain header fields. Uh, so, the suggestion is to add a new flag, which basically means do not send feedback to people before me. Uh, which a privacy preserving forwarder would add, uh, if they did so, uh, but, uh, for, for most cases, people I wouldn't expect very many people to be setting this flag at all. Um, we can explore the notion that feedback, uh, in such cases should be sent to the person who added the flag, who will then distribute it appropriately, um, but that is, a, complicated, and b, the whole of the feedback stuff is deliberately out of scope for the specification document.

Pete Resnick: Bron, you have your hand up. And then Dave had a comment in the room that I'm trying to parse, yep.

Bron Gondwana: Yeah, I'm actually in the queue this time. Regarding the null header recipes, I replied to someone on the list recently who was doing a privacy protecting sending system, um, and I think that's precisely this kind of case, the null header recipe. And in that case, basically what you want to do is keep a copy of the message in some local database for a period of time so that you can generate bounces for it, and then generate a brand new message with brand new DKIM2 headers and no history on it at all, um, in which case all of this is moot. You can't have null header recipes in DKIM2, you just strip them all off and start again, and then if you get a bounce back, you create the brand new message for the rest of the response. And I think that is fine. Um, if you want to do, if you want to do null headers, then you've got to take responsibility for the message entirely and start it from scratch. So, in summary, I agree with Richard. No null header recipes.

Pete Resnick: And, that does sound to me like, um, uh, when, when you introduce that time where you're actually doing these, these replacements and don't want to tell anybody about them, it is the equivalent of the traditional gateway function where you're actually moving it from one environment to another. In this case, it's still within, you know, standard SMTP land, but you are doing something to the message that is in effect a delivery and a re-sending.

Um, anybody else?

Comments on any of these.

And I'll take Bron out of the queue.

And I'm just reading, uh, Dave's comment here in the, uh, chat, presuming he doesn't jump in on audio because it's not a convenient place for him to do so. But if others want to take a quick, quick look at that.

Dave Crocker: My audio's working, but I, I figured what I wrote probably clarified it enough.

Pete Resnick: Okay.

Yeah, and, and, you know, I agree with this. One of the things that I think, um, and, and I'd appreciate Dave you jumping in and I, you know, certainly with chair hat on going to have to do it, as we go along and eventually, but, you know, Murray and I were chatting the other week and, uh, you know, ran across a, oh, where we, it's another document where we're going to have to go through and carefully separate out headers from header fields, and, you know, we, you know, getting vocabulary right is always a pain in the butt, but this is exactly the kind of document where we're going to have to get things and the model clear in the document, as clear as we can. So we're going to need a couple of, uh, old fogies or people with sufficient amounts of, uh, um, you know, anal-retentiveness to go and take a look at these things. Bron?

Bron Gondwana: I wanted to ask Dave, did what I said about the cases where you wanted to not keep the DKIM2 header recipes completely intact be that you're starting from scratch? Is that sufficiently descriptive? The situation is any case where you're taking a message, making changes to it, and retaining the existing DKIM2 signature header and message instance headers is a case where you are, I guess, relaying the message, not re-posting the message, and any case where you're stripping off the existing DKIM2 headers is a case where you're re-posting the message. And regardless of what your internal structure is and what you name the parts of it, that's the distinction, whether you're keeping those headers or not.

Dave Crocker: So, what you've just said was very behavioral, which is excellent. Um, it is not, um, automatically linked to the terminology distinction I was making, um, and, and I'm saying that not because I think you should have made the linkage, I'm saying that I think the community discussion fails to make the distinction and make the linkage, um, and that we have people floating around who say MTA when they mean gateway. Uh, I don't think I hear people use the term gateway, and so, um, uh, your clarity of behavioral distinction is, um, uh, essential, but I think that linking it to the right terminology, uh, is also essential, and, um, especially if you intend anyone outside of the immediate folk working on this to be consistent in how they take the specs, um, would be very helpful.

Pete Resnick: And, and I'll say, Dave, I, I'm, one of my reactions to, you know, your comment here is I'm both afraid, but, you know, think maybe it is necessary, that we may need an, another piece of vocabulary to describe this something in between, or we're at least going to have to describe, you know, what the features are that constitute the gateway in this case and what the features are that constitute an MTA in this case. Um, and, and they are probably, yeah, I, I'm, I'm unconvinced that we're not inventing some little new piece in the middle of the architecture.

Dave Crocker: There, there has been, um, really impressive resistance to, uh, adopting the term gateway, which was originally chosen way back when the architecture document was used. Right. Nobody particularly liked it, but nobody came up with a better one. Uh, and so people continue to not like it, but not come up with a better one. Um, I, I, I, I, I, I translate this down to, um, fairly specific bit of behavior, which is if, which is resubmitting. Uh, if a message shows up at the address it's being sent to, uh, it's delivered. Uh, or rejected, but, but let's ignore that case for the moment. And if it is, uh, sent to a new address, then it's been resubmitted, re-posted. And, um, that thing that is doing the re-posting, uh, is a gateway or whatever the fuck name you want to give it, I don't actually care. Um, I only say gateway because that's been around a long time and it was a serviceable term for a long time. Uh, but, but I'm more concerned about having, uh, precise definitions, precise labeling to go with the definitions, and then the hardest part of all is getting people to use those labels and distinctions consistently.

Pete Resnick: Yeah, I, I think the, um, concern I've got is the case that, um, Bron's talking about where you've got something in your network which, um, is, I, I even hate to use these words because they're not exactly right, which is not doing final delivery into a mailbox. Um, and yet is making changes to the message is doing something that is local to the administrative domain. And I think that's the gateway, um, because it's in your domain and the thing doing the changes is doing them on behalf of the recipient. But, um, it's doing something weirder than what I, at least, I thought of back in the day as a gateway function.

Dave Crocker: I, I think you have nicely demonstrated the confusion people have about what constitutes delivery. I, I think that everything you said embodies, uh, the kind of distinction people make, um, and, and I will claim that's mostly because of being really tied to implementation details rather than conceptual details. Um, and, the, the fact that it doesn't go into a bit of storage called inbox or equivalent, um, is, in my view, completely irrelevant. It is, the, the processing for the target address is completed. Uh, it's completed in a fashion which redirects the message to a new address, but that's, uh, a, a, an activity above delivery. In this case, it's the implementation is integrated, or maybe it's integrated, because it's common in some environments for this function to actually be done by, uh, for a message that actually goes to an inbox and then is processed by separate software. A list manager is an example of exactly the thing you described, except it's a separate application, separate implementation, and, uh, is a form of gateway.

By the way, I repeat, I don't care if that's the word used, I just like one word used for that, uh, architectural role and used consistently and precisely.

Pete Resnick: Yep. I hear you.

All right. Um, well, like I said, we've got vocabulary cleanup to do here as well as making sure we agree that, um, this is, at least for the protocol, the way to go forward. Um, does anybody have any concerns about the protocol issue of saying that we do not need this mechanism for null changes? Or, I'm sorry, uh, null recipes.

All right. Well, um, we'll summarize and put this on the list. This is one where, um, you'll, uh, yes, null header recipes. Thank you, Bron, that's very important distinction. Um, this is one, and if you end up preparing a new draft before minutes of this go out, um, Richard, do kind of highlight the pieces that are changing, what was discussed on the interim, that way people are not surprised to find out that there's a new thing in the document that they've never heard of before, so.

Richard Clayton: I, I, of course, I will do that. I just wanted to say that, um, first of all, uh, I put considerable effort into saying header field rather than headers, etc., uh, already. Uh, and secondly, that the document does in fact, since you'll all read it, you'll, you'll know and recall that it has a definition of a thing we call a forwarder, uh, and there is a discussion where that forwarder is defined as to its relation, what relationship it might have with the terms from the architecture document.

Pete Resnick: Very good.

Um, a, a, a, the, the, context in which, the context in which Murray and I were noting, uh, ambiguity was mostly on the list and not in the document. Um, so that may be a, uh, an unfair leak onto criticism of your document.

But,

Richard Clayton: Right, we, we, we'll, I'm sure we can tidy it up and I'm sure, uh, there may be places where, uh, forwarders has not, has not been used consistently with elsewhere, etc. But that's why we get many people to read it.

Pete Resnick: Ack, yeah.

All right. Well, um, then I will snatch the mic from you and hand it over to Bron to talk about, uh, uh, his issue, which I, uh, failed to do earlier.

Bron Gondwana: Thank you. Murray, I sent you some slides immediately before this meeting started, sorry for the very lateness. Have you been able to upload them?

Murray Kucherawy: I uploaded them before the meeting started.

Bron Gondwana: Sweet.

Murray Kucherawy: So they should be in the set there.

Bron Gondwana: So I guess if I ask for slide control, then I should be able to present them.

They are not present in the view I can see. I only have Chair slides and AOB Richard Clayton.

Pete Resnick: That's weird because I, did I, did I not get it all the way there? Hold on. Sometimes you have to click a refresh button on to make MeetEcho rescan. Meteco, or whatever you want to call it.

Pete Resnick: Right, they weren't in the tracker. They are there now. Let me see if the, yes, they're available through MeetEcho now. You still have control?

Bron Gondwana: Uh, I'm requesting it again.

Pete Resnick: Okay, here it comes.

Bron Gondwana: Sweet, thank you.

Pete Resnick: Yep.

The important thing is that if you mention it in this thing, and we can call it whatever we like, the important thing is that you add a recipe for that X-header into the header recipes, and then the following rule from that is that if you create a new message instance, you must include, if you change any X-header that was mentioned in a previous message instance recipe, then you need to add a recipe for the change that you make to that header from there on. You can't touch any header that's mentioned in a previous recipe without giving a recipe for it. And that's the only, that's the only change. That then allows you to have reliable hashes for any header that's not already hashed, but you just have to check it in the previous message instances and you have to make sure you create recipes if you change it.

Allen?

Allen Robinson: How is this different from if we just put the HN equals into message instance? Like, this, isn't, this stops being optional when everybody has to, you know, deal with this when they make changes.

Bron Gondwana: That's true. It's not, it would probably actually be easier to add the HN to message instance, and if anything is in HN, then it's included in the set, and everyone afterwards has to also include the same HN or additional HN if it wants to add anything new.

Allen Robinson: Okay.

Bron Gondwana: Cool. Um, I think that's a better solution.

True. Um, but I think, I think the as a, as an escape valve, it gives us an escape valve. And then you would explicitly say this is, this is also signed. On the other hand, that adds complexity.

Pete?

I, I actually, Richard first, then Pete.

I'm sure Richard is going to say I hate the idea and we shouldn't do it, which is a perfect...

Richard Clayton: I hate the idea we shouldn't do it. Um, um, and you should stop putting in X-foo headers and you should Y-foo headers in, at which point, they will automatically be handled by systems whichever body has there already and nobody has to do extra special handling at all.

Bron Gondwana: That seems perfectly reasonable to me. I just wanted to write up what the proposal was, and already Allen has a better proposal which we also shouldn't do.

Pete.

Pete Resnick: So, John asks in the room who wants this, and um, at least Pete, um, in addition to Vittorio.

So here's my problem. It's not that, of course, you shouldn't create a Y- or a, you know, uh, Pete's wonderful header- or whatever it is. Um, it's that we have seen repeatedly instances where semantics of an X-field leak. And it doesn't matter if that semantics is dangerous or I, I disagree with Vittorio on this, it's not, it's not about, you know, whether the world comes crashing down because of it. It's that as soon as something starts interpreting those X-dash fields in some way other than ignoring them, then I might want to say, oh, well now that I know that Bron is an idiot and is interpreting these X-dash fields in a particular way, I can sneak one in in the middle of the chain and Bron's going to go and interpret it that way and I can maybe mess with him in some way that he has not anticipated. And if that is, and that can be for any field that would somehow meet the non-signed form. Um, maybe I've come up with a new tag in received and everybody starts using it, um, and, uh, you know, I do something nasty.

The ability to say, no, I meant it this way and you better make sure that you've got it since I now know as the sender that people down the line are interpreting the semantics of this, um, seems like an easy enough mechanism without a whole lot of pain to just go ahead and add it.

Bron Gondwana: I think Richard already answered this pretty capably, which is, um, we shouldn't put soft-padded helmets on everybody to stop people punching themselves in the head, I guess is, is one way of putting it. Um, if you, if you're going to interpret something as having meaning, you should start it with something other than X- and then it's automatically covered. And people who are doing the wrong thing, um, like people who are adding new behavior to X-dash headers and believing new behavior from X-dash headers are punching themselves in the head deliberately, is what I'm saying.

Bron Gondwana: Yeah, specifically to answer Trent's question explicitly, the purpose of next D is to say the next domain is me as well, I, this is a trust relationship between these two domains. And the purpose of all the other relationships is this is not a trust relationship between these two domains. I'm sending this across the internet to someone I don't know anything about other than that they have this receipt to email address. So they're two distinct cases, and we don't really want to conflate them. If you see next D, that should be, this is me signing again, or this is someone I trust signing again, and, and we have a relationship.

Pete Resnick: All right, Brian, you're up.

Pete Resnick: All right, Dave is next.

Dave Crocker: Yeah, I just wanted to know um, a few things here. One, I I do really like uh, this outcome, um, specifically what I appreciate is being able to see the, uh, actual destination recipient to um, intended by the, um, you know, i=1, the initial d=domain signing, like that this is the intended recipient. So I really like seeing that.

Pete Resnick: Okay, any other comments on this before we move on?

Dave Crocker: No, not from me.

Pete Resnick: Okay.

Bron Gondwana: The other thing is, um, hashed body properties. So this was the thing that came up a while ago about being able to hash individual MIME parts. And what I talked about briefly at the last meeting and only throw it up now, was the idea, sorry, I've just skipped past the slide that described this. Which was rather than having a completely null recipe that says no changes to the body described at all, basically say, "I have redacted this many lines at this point in the body recipe." And so that would then allow you to chop out an attachment, for example, while still keeping the text and HTML parts of a multipart consistent, and you could recreate the original message just with a blanked out attachment, such that somebody could check back the original signature and say, "Well, the ranged hash for lines 3 to 20 was this, and lines 3 to 20 was a complete MIME part." So, that MIME part is consistent to what was there originally. Um, so you can tell that those particular lines were unchanged, and by using line offsets and by saying how many lines you're deleting when you cut something out, um, that you're refusing to state what was in there before, we could then allow you to recreate parts of it and to check the hashes on parts of it. That's, that's basically the proposal.

To do it, you would require to be able to look back through a, a partially redacted chain. You would require whoever was doing that redaction to specify which lines they nuked, rather than just say, "I made changes, trust me." If you had that, then you could do the range hashes thing, and it would just work.

Um, these are some of the properties and details on it. Obviously, you would only trust a complete MIME part. The fact that we're doing this with lines has the advantage of not requiring software that can understand IMAP MIME parts and, and them for addressing, and instead just work with lines because we already work with lines. But it does have the risk that you could have a partial, like, just hash part of a, a part rather than the entire part and then you could falsify the bits that weren't covered by the hash, which is the same issue that length equals had with the original DKIM. And then, this is not too hard to do. It's pretty easy to just start a separate hash immediately after each MIME separator when you're the originator of the message. You generally wouldn't add a new one of these along the way, uh, unless you were changing things in a way that you expected to need to be able to do this for. And if you did, then you would use the recipe to replace the old, hash parts, or hash lines header with a new one and, then you could, the regular undo would give you the old one for previous message instances.

So, that's, that's the whole spec for this one.

Pete Resnick: Comments from the floor? I'm still kind of digesting this.

Oh, go ahead Richard.

Richard Clayton: I don't see what the incentive is. Since you don't get any trust, if somebody does this in the middle of the chain, you're back in the position of you have to trust them, and why should anybody? Unless you have a contract with them, at which point, you can use the null recipe and press on that way. If you think that people are going to sign some ranges of a message at the beginning of the chain, gratuitously out of the goodness of their heart so that people can chop up their message thereafter, um, I don't see why anybody would wish to bother to do that. And it's complicated to understand, and complicated to work out what the trust is, and rather like L equals, people will end up using it in dumb ways and make the world far less safe.

Bron Gondwana: So the, certainly the argument case, in the second dot point there, you can download only the start of the message and verify that particular MIME parts haven't been tampered with. And this was the case that the Apple client people in particular wanted to be able to do, to download a message and check that the, the MIME parts, that they could then validate those without having to download the entire message.

That's basically the argument for that.

Pete Resnick: Alan?

Allen Robinson: To Richard's point, I think this only works if everybody has to do it at every hop.

Bron Gondwana: Oh, the first hop. At least, at the first hop, at least. Generally the, the other hops don't, unless they don't provide a way to undo back to the original part. But you stop being able to undo their changes in a way that you can verify their hashes because you've lost a part that they hashed. Only people who are wiping out lines make any difference there. Otherwise, if lines haven't been wiped out, then the regular undo recipes still work, and the regular undo recipes, because they're all line-based, still work through one of these deletions, because you just say these lines have been redacted, but all the line offsets still undo correctly. So you can get back to the original line offsets in the original message, even if you can't see all of them.

Allen Robinson: Okay.

Bron Gondwana: Cool. Um, I think that's a better solution.

True. Um, but I think, I think the as a, as an escape valve, it gives us an escape valve. And then you would explicitly say this is, this is also signed. On the other hand, that adds complexity.

Pete?

I, I actually, Richard first, then Pete.

I'm sure Richard is going to say I hate the idea and we shouldn't do it, which is a perfect...

Bron Gondwana: That seems perfectly reasonable to me. I just wanted to write up what the proposal was, and already Allen has a better proposal which we also shouldn't do.

Pete.

Pete Resnick: So, John asks in the room who wants this, and um, at least Pete, um, in addition to Vittorio.

Bron Gondwana: Yeah, specifically to answer Dave's question explicitly, the purpose of next D is to say the next domain is me as well, I, this is a trust relationship between these two domains. And the purpose of all the other relationships is this is not a trust relationship between these two domains. I'm sending this across the internet to someone I don't know anything about other than that they have this receipt to email address. So they're two distinct cases, and we don't really want to conflate them. If you see next D, that should be, this is me signing again, or this is someone I trust signing again, and, and we have a relationship.

Pete Resnick: All right, Brian, you're up.

Pete Resnick: Okay, any other comments on this before we move on?

Dave Crocker: No, not from me.

Pete Resnick: Okay.

Dave Crocker: There, there has been, um, really impressive resistance to, uh, adopting the term gateway, which was originally chosen way back when the architecture document was used. Right. Nobody particularly liked it, but nobody came up with a better one. Uh, and so people continue to not like it, but not come up with a better one. Um, I, I, I, I, I, I translate this down to, um, fairly specific bit of behavior, which is if, which is resubmitting. Uh, if a message shows up at the address it's being sent to, uh, it's delivered. Uh, or rejected, but, but let's ignore that case for the moment. And if it is, uh, sent to a new address, then it's been resubmitted, re-posted. And, um, that thing that is doing the re-posted, uh, is a gateway or whatever the fuck name you want to give it, I don't actually care. Um, I only say gateway because that's been around a long time and it was a serviceable term for a long time. Uh, but, but I'm more concerned about having, uh, precise definitions, precise labeling to go with the definitions, and then the hardest part of all is getting people to use those labels and distinctions consistently.

Pete Resnick: Yep. I hear you.

Pete Resnick: Very good.

Um, a, a, a, the, context in which, the context in which Murray and I were noting, uh, ambiguity was mostly on the list and not in the document. Um, so that may be a, uh, an unfair leak onto criticism of your document.

But,

Pete Resnick: Ack, yeah.

All right. Well, um, then I will snatch the mic from you and hand it over to Bron to talk about, uh, uh, his issue, which I, uh, failed to do earlier.

Bron Gondwana: Thank you. Murray, I sent you some slides immediately before this meeting started, sorry for the very lateness. Have you been able to upload them?

Murray Kucherawy: I uploaded them before the meeting started.

Bron Gondwana: Sweet.

Murray Kucherawy: So they should be in the set there.

Bron Gondwana: So I guess if I ask for slide control, then I should be able to present them.

They are not present in the view I can see. I only have Chair slides and AOB Richard Clayton.

Pete Resnick: Right, they weren't in the tracker. They are there now. Let me see if the, yes, they're available through MeetEcho now. You still have control?

Bron Gondwana: Uh, I'm requesting it again.

Pete Resnick: Okay, here it comes.

Bron Gondwana: Sweet, thank you.

Pete Resnick: Yep.

Bron Gondwana: All right. So this was something that I, I guess I spoke about on the fly during the last call, late at ridiculously late at night for me over in Europe. And I thought I should write it up a bit more properly so that we can talk about it this time. I don't know if we want to go ahead with it, but there are two things. The first is hashing of X-headers. There's a proposal for allowing you to make your X-headers unfakeable. And so, I proposed a new field, Message-X-Headers, which has a list of the header names that are being hashed, and a SHA-256 of those header names. Yeah, meh, is is ideal. In exactly the same shape, but you have to name the specific headers that are on there, and otherwise you would use the, the same calculation, start from the bottom, sort them alphabetically, and I guess maybe require them alphabetically there too because I've put them the other way around, but we could specify exactly how this is done. The important thing is that if you mention it in this thing, and we can call it whatever we like, the important thing is that you add a recipe for that X-header into the header recipes, and then the following rule from that is that if you create a new message instance, you must include, if you change any X-header that was mentioned in a previous message instance recipe, then you need to add a recipe for the change that you make to that header from there on. You can't touch any header that's mentioned in a previous recipe without giving a recipe for it. And that's the only, that's the only change. That then allows you to have reliable hashes for any header that's not already hashed, but you just have to check it in the previous message instances and you have to make sure you create recipes if you change it.

Alan?

Allen Robinson: Okay.

Bron Gondwana: Cool. Um, I think that's a better solution.

True. Um, but I think, I think the as a, as an escape valve, it gives us an escape valve. And then you would explicitly say this is, this is also signed. On the other hand, that adds complexity.

Pete?

I, I actually, Richard first, then Pete.

I'm sure Richard is going to say I hate the idea and we shouldn't do it, which is a perfect...

Bron Gondwana: That seems perfectly reasonable to me. I just wanted to write up what the proposal was, and already Allen has a better proposal which we also shouldn't do.

Pete.

Pete Resnick: So, John asks in the room who wants this, and um, at least Pete, um, in addition to Vittorio.

Pete Resnick: All right, Brian, you're up.

Pete Resnick: Okay, any other comments on this before we move on?

Dave Crocker: No, not from me.

Pete Resnick: Okay.

Pete Resnick: Yep. I hear you.

Pete Resnick: Very good.

But,

Pete Resnick: Ack, yeah.

All right. Well, um, then I will snatch the mic from you and hand it over to Bron to talk about, uh, uh, his issue, which I, uh, failed to do earlier.

Bron Gondwana: Thank you. Murray, I sent you some slides immediately before this meeting started, sorry for the very lateness. Have you been able to upload them?

Murray Kucherawy: I uploaded them before the meeting started.

Bron Gondwana: Sweet.

Murray Kucherawy: So they should be in the set there.

Bron Gondwana: So I guess if I ask for slide control, then I should be able to present them.

They are not present in the view I can see. I only have Chair slides and AOB Richard Clayton.

Pete Resnick: Right, they weren't in the tracker. They are there now. Let see if the, yes, they're available through MeetEcho now. You still have control?

Bron Gondwana: Uh, I'm requesting it again.

Pete Resnick: Okay, here it comes.

Bron Gondwana: Sweet, thank you.

Pete Resnick: Yep.

Bron Gondwana: All right. So this was something that I, I guess I spoke about on the fly during the last call, late at ridiculously late at night for me over in Europe. And I thought I should write it up a bit more properly so that we can talk about it this time. I don't know if we want to go ahead with it, but there are two things. The first is hashing of X-headers. There's a proposal for allowing you to make your X-headers unfakeable. And so, I proposed a new field, Message-X-Headers, which has a list of the header names that are being hashed, and a SHA-256 of those header names. Yeah, meh, is is ideal. In exactly the same shape, but you have to name the specific headers that are on there, and otherwise you would use the, the same calculation, start from the bottom, sort them alphabetically. And I guess maybe require them alphabetically there too because I've put them the other way around, but we could specify exactly how this is done. The important thing is that if you mention it in this thing, and we can call it whatever we like, the important thing is that you add a recipe for that X-header into the header recipes, and then the following rule from that is that if you create a new message instance, you must include, if you change any X-header that was mentioned in a previous message instance recipe, then you need to add a recipe for the change that you make to that header from there on. You can't touch any header that's mentioned in a previous recipe without giving a recipe for it. And that's the only, that's the only change. That then allows you to have reliable hashes for any header that's not already hashed, but you just have to check it in the previous message instances and you have to make sure you create recipes if you change it.

Alan?

Allen Robinson: Okay.

Bron Gondwana: Cool. Um, I think that's a better solution.

True. Um, but I think, I think the as a, as an escape valve, it gives us an escape valve. And then you would explicitly say this is, this is also signed. On the other hand, that adds complexity.

Pete?

I, I actually, Richard first, then Pete.

I'm sure Richard is going to say I hate the idea and we shouldn't do it, which is a perfect...

Bron Gondwana: That seems perfectly reasonable to me. I just wanted to write up what the proposal was, and already Allen has a better proposal which we also shouldn't do.

Pete.

Pete Resnick: So, John asks in the room who wants this, and um, at least Pete, um, in addition to Vittorio.

Pete Resnick: All right, Brian, you're up.

Pete Resnick: Okay, any other comments on this before we move on?

Dave Crocker: No, not from me.

Pete Resnick: Okay.

Pete Resnick: Yep. I hear you.

Pete Resnick: Very good.

But,

Pete Resnick: Ack, yeah.

All right. Well, um, then I will snatch the mic from you and hand it over to Bron to talk about, uh, uh, his issue, which I, uh, failed to do earlier.

Bron Gondwana: Thank you. Murray, I sent you some slides immediately before this meeting started, sorry for the very lateness. Have you been able to upload them?

Murray Kucherawy: I uploaded them before the meeting started.

Bron Gondwana: Sweet.

Murray Kucherawy: So they should be in the set there.

Bron Gondwana: So I guess if I ask for slide control, then I should be able to present them.

They are not present in the view I can see. I only have Chair slides and AOB Richard Clayton.

Pete Resnick: Right, they weren't in the tracker. They are there now. Let see if the, yes, they're available through MeetEcho now. You still have control?

Bron Gondwana: Uh, I'm requesting it again.

Pete Resnick: Okay, here it comes.

Bron Gondwana: Sweet, thank you.

Pete Resnick: Yep.

Bron Gondwana: All right. So this was something that I, I guess I spoke about on the fly during the last call, late at ridiculously late at night for me over in Europe. And I thought I should write it up a bit more properly so that we can talk about it this time. I don't know if we want to go ahead with it, but there are two things. The first is hashing of X-headers. There's a proposal for allowing you to make your X-headers unfakeable. And so, I proposed a new field, Message-X-Headers, which has a list of the header names that are being hashed, and a SHA-256 of those header names. Yeah, meh, is is ideal. In exactly the same shape, but you have to name the specific headers that are on there, and otherwise you would use the, the same calculation, start from the bottom, sort them alphabetically. And I guess maybe require them alphabetically there too because I've put them the other way around, but we could specify exactly how this is done. The important thing is that if you mention it in this thing, and we can call it whatever we like, the important thing is that you add a recipe for that X-header into the header recipes, and then the following rule from that is that if you create a new message instance, you must include, if you change any X-header that was mentioned in a previous message instance recipe, then you need to add a recipe for the change that you make to that header from there on. You can't touch any header that's mentioned in a previous recipe without giving a recipe for it. And that's the only, that's the only change. That then allows you to have reliable hashes for any header that's not already hashed, but you just have to check it in the previous message instances and you have to make sure you create recipes if you change it.

Alan?

Allen Robinson: Okay.

Bron Gondwana: Cool. Um, I think that's a better solution.

True. Um, but I think, I think the as a, as an escape valve, it gives us an escape valve. And then you would explicitly say this is, this is also signed. On the other hand, that adds complexity.

Pete?

I, I actually, Richard first, then Pete.

I'm sure Richard is going to say I hate the idea and we shouldn't do it, which is a perfect...

Bron Gondwana: That seems perfectly reasonable to me. I just wanted to write up what the proposal was, and already Allen has a better proposal which we also shouldn't do.

Pete.

Pete Resnick: So, John asks in the room who wants this, and um, at least Pete, um, in addition to Vittorio.

Pete Resnick: All right, Brian, you're up.

Pete Resnick: Okay, any other comments on this before we move on?

Dave Crocker: No, not from me.

Pete Resnick: Okay.

Pete Resnick: Yep. I hear you.

Pete Resnick: Very good.

But,

Pete Resnick: Ack, yeah.

All right. Well, um, then I will snatch the mic from you and hand it over to Bron to talk about, uh, uh, his issue, which I, uh, failed to do earlier.

Bron Gondwana: Thank you. Murray, I sent you some slides immediately before this meeting started, sorry for the very lateness. Have you been able to upload them?

Murray Kucherawy: I uploaded them before the meeting started.

Bron Gondwana: Sweet.

Murray Kucherawy: So they should be in the set there.

Bron Gondwana: So I guess if I ask for slide control, then I should be able to present them.

They are not present in the view I can see. I only have Chair slides and AOB Richard Clayton.

Pete Resnick: Right, they weren't in the tracker. They are there now. Let see if the, yes, they're available through MeetEcho now. You still have control?

Bron Gondwana: Uh, I'm requesting it again.

Pete Resnick: Okay, here it comes.

Bron Gondwana: Sweet, thank you.

Pete Resnick: Yep.

Bron Gondwana: All right. So this was something that I, I guess I spoke about on the fly during the last call, late at ridiculously late at night for me over in Europe. And I thought I should write it up a bit more properly so that we can talk about it this time. I don't know if we want to go ahead with it, but there are two things. The first is hashing of X-headers. There's a proposal for allowing you to make your X-headers unfakeable. And so, I proposed a new field, Message-X-Headers, which has a list of the header names that are being hashed, and a SHA-256 of those header names. Yeah, meh, is is ideal. In exactly the same shape, but you have to name the specific headers that are on there, and otherwise you would use the, the same calculation, start from the bottom, sort them alphabetically. And I guess maybe require them alphabetically there too because I've put them the other way around, but we could specify exactly how this is done. The important thing is that if you mention it in this thing, and we can call it whatever we like, the important thing is that you add a recipe for that X-header into the header recipes, and then the following rule from that is that if you create a new message instance, you must include, if you change any X-header that was mentioned in a previous message instance recipe, then you need to add a recipe for the change that you make to that header from there on. You can't touch any header that's mentioned in a previous recipe without giving a recipe for it. And that's the only, that's the only change. That then allows you to have reliable hashes for any header that's not already hashed, but you just have to check it in the previous message instances and you have to make sure you create recipes if you change it.

Alan?

Allen Robinson: Okay.

Bron Gondwana: Cool. Um, I think that's a better solution.

True. Um, but I think, I think the as a, as an escape valve, it gives us an escape valve. And then you would explicitly say this is, this is also signed. On the other hand, that adds complexity.

Pete?

I, I actually, Richard first, then Pete.

I'm sure Richard is going to say I hate the idea and we shouldn't do it, which is a perfect...

Bron Gondwana: That seems perfectly reasonable to me. I just wanted to write up what the proposal was, and already Allen has a better proposal which we also shouldn't do.

Pete.

Pete Resnick: So, John asks in the room who wants this, and um, at least Pete, um, in addition to Vittorio.

Bron Gondwana: To do a poll? Yeah, we'll run a poll of the room and see what people think. Let's see where the, where the sense is.

Pete Resnick: I'm happy to. Um, I can do up a little poll. And I'm thinking,

Bron Gondwana: We might as well, we've got the tool, might as well. And it's, it's not a hill that I care to die on either way, but um, yeah, would be good to see.

Pete Resnick: Yep, um, so I will say, "Ability to sign particular X-dash: Worth it? Yes. Not worth it? No." How's that?

Bron Gondwana: Yeah.

Pete Resnick: I'll stay out of the poll.

Pete Resnick: And okay, I mean, is that everybody? How many do we have here today? 13.

That's close to everybody.

Bron Gondwana: It's a, it's a strong but not, not unanimous, but a few didn't vote. There's two other people who voted yes.

Pete Resnick: That's right, and, and, so, so, do the yeses want to say something since they are clearly in the minority end of this?

Alan, are you a yes? Wei, are you a yes?

Allen Robinson: Uh, I mean, maybe we are both the yeses, uh,

Richard Clayton: I didn't push the button, so.

Allen Robinson: Oops. Um, I I think this is so easy to implement that it's just, it's, it's not worth removing the ability to sign this. Like, we have the ability to sign these with DKIM. Is it needed? No, we've we've talked about a whole bunch of options that make this work. Right, if you're, if you're a DKIM2 signer that's happening after something that adds an X-header, you can just change the name of it. You don't have to declare that you changed the name of it because it wasn't signed in the first place, and then it becomes signed because you've changed the name to be something that, that would be covered by DKIM2. But, like, I think this is cheap enough that it's worth just avoiding all of that.

Pete Resnick: Wei?

Wei Chuang: Yeah, plus one to what Alan said. Um, basically, I don't, sure, these things are in the eyes of some, abhorrent and problematic, but I think they exist, and they exist for a reason, and covers, or solves my concerns. Um, I think, yes, we will see other instances where we may need, uh, multiple signatures in one ADMD. Uh, certainly is an enterprise issue. I think there's other places where like for feedback or for other things, uh, that this will become a more common place pattern, uh, especially like beyond just, you know, that's already happening in the ESP space, but I think other places will, uh, want to show relationships and this is a way of doing that type of thing.

Pete Resnick: Bron?

Bron Gondwana: I wanted to ask Dave did what I said about the cases where you wanted to not keep the DKIM2 header recipes completely intact be that you're starting from scratch? Is that sufficiently descriptive? The situation is any case where you're taking a message, making changes to it, and retaining the existing DKIM2 signature header and message instance headers is a case where you are, I guess, relaying the message, not re-posting the message, and any case where you're stripping off the existing DKIM2 headers is a case where you're re-posting the message. And regardless of what your internal structure is and what you name the parts of it, that's the distinction, whether you're keeping those headers or not.

Pete Resnick: Alright, Brian, you're up.

Pete Resnick: Okay, any other comments on this before we move on?

Dave Crocker: No, not from me.

Pete Resnick: Okay.

Pete Resnick: Yep. I hear you.

Pete Resnick: Very good.

But,

Pete Resnick: Ack, yeah.

All right. Well, um, then I will snatch the mic from you and hand it over to Bron to talk about, uh, uh, his issue, which I, uh, failed to do earlier.

Bron Gondwana: Thank you. Murray, I sent you some slides immediately before this meeting started, sorry for the very lateness. Have you been able to upload them?

Murray Kucherawy: I uploaded them before the meeting started.

Bron Gondwana: Sweet.

Murray Kucherawy: So they should be in the set there.

Bron Gondwana: So I guess if I ask for slide control, then I should be able to present them.

They are not present in the view I can see. I only have Chair slides and AOB Richard Clayton.

Pete Resnick: Right, they weren't in the tracker. They are there now. Let see if the, yes, they're available through MeetEcho now. You still have control?

Bron Gondwana: Uh, I'm requesting it again.

Pete Resnick: Okay, here it comes.

Bron Gondwana: Sweet, thank you.

Pete Resnick: Yep.

Bron Gondwana: All right. So this was something that I, I guess I spoke about on the fly during the last call, late at ridiculously late at night for me over in Europe. And I thought I should write it up a bit more properly so that we can talk about it this time. I don't know if we want to go ahead with it, but there are two things. The first is hashing of X-headers. There's a proposal for allowing you to make your X-headers unfakeable. And so, I proposed a new field, Message-X-Headers, which has a list of the header names that are being hashed, and a SHA-256 of those header names. Yeah, meh, is is ideal. In exactly the same shape, but you have to name the specific headers that are on there, and otherwise you would use the, the same calculation, start from the bottom, sort them alphabetically. And I guess maybe require them alphabetically there too because I've put them the other way around, but we could specify exactly how this is done. The important thing is that if you mention it in this thing, and we can call it whatever we like, the important thing is that you add a recipe for that X-header into the header recipes, and then the following rule from that is that if you create a new message instance, you must include, if you change any X-header that was mentioned in a previous message instance recipe, then you need to add a recipe for the change that you make to that header from there on. You can't touch any header that's mentioned in a previous recipe without giving a recipe for it. And that's the only, that's the only change. That then allows you to have reliable hashes for any header that's not already hashed, but you just have to check it in the previous message instances and you have to make sure you create recipes if you change it.

Alan?

Allen Robinson: Okay.

Bron Gondwana: Cool. Um, I think that's a better solution.

True. Um, but I think, I think the as a, as an escape valve, it gives us an escape valve. And then you would explicitly say this is, this is also signed. On the other hand, that adds complexity.

Pete?

I, I actually, Richard first, then Pete.

I'm sure Richard is going to say I hate the idea and we shouldn't do it, which is a perfect...

Bron Gondwana: That seems perfectly reasonable to me. I just wanted to write up what the proposal was, and already Allen has a better proposal which we also shouldn't do.

Pete.

Pete Resnick: So, John asks in the room who wants this, and um, at least Pete, um, in addition to Vittorio.

Bron Gondwana: So we move on.

Pete Resnick: I was just going to give a nudge. Go ahead.

Bron Gondwana: Here's the other thing. Um, hashed body properties. So this was the thing that came up a while ago about being able to hash individual MIME parts. And what I talked about briefly at the last meeting and only throw it up now, was the idea, sorry, I've just skipped past the slide that described this. Which was rather than having a completely null recipe that says no changes to the body described at all, basically say, "I have redacted this many lines at this point in the body recipe." And so that would then allow you to chop out an attachment, for example, while still keeping the text and HTML parts of a multipart consistent, and you could recreate the original message just with a blanked out attachment, such that somebody could check back the original signature and say, "Well, the ranged hash for lines 3 to 20 was this, and lines 3 to 20 was a complete MIME part." So, that MIME part is consistent to what was there originally. Um, so you can tell that those particular lines were unchanged, and by using line offsets and by saying how many lines you're deleting when you cut something out, um, that you're refusing to state what was in there before, we could then allow you to recreate parts of it and to check the hashes on parts of it. That's, that's basically the proposal.

So, that's, that's the whole spec for this one.

Pete Resnick: Okay, um, anything further? I mean, it sounds like we can continue to talk about the hash thing, probably in Vienna. Um, anything further on any of that? Or we go to I think Wei, I don't Wei, I don't have any slides from you, um, do you just want to wing it?

Wei Chuang: I didn't, sorry, I wasn't, uh, particularly well prepared. Um, I don't think any updates have come in on the DNS, um, so I don't really have anything to talk about.

Pete Resnick: Okay. I mean, I think that that topic, it's, it's newish since the last time we met, I think, in an interim, so we can, um, schedule some time to, to talk about it if we still need to at Vienna.

Wei Chuang: Sure.

Pete Resnick: The multi, I'm talking about the multiple domains suggestion you had. Um, I don't think we've fully aired it out yet.

Wei Chuang: Oh, I see. Um, the multiple domains, no, I thought, I thought we came to resolution right here, actually. I mean, I think the, the thing that Tobias has, um, uh, proposed will satisfy my, my particular set of concerns.

Pete Resnick: Oh, that's, oh, that's good.

Wei Chuang: I don't know if there's more to talk about.

Pete Resnick: Um, looking for, looking back at the thread, oh, Tobias's, I get it. I remember this. I didn't realize it had fully resolved. I'm sorry. Okay, didn't mean to put you on the spot.

Wei Chuang: Okay.

Pete Resnick: Um, in that case, uh, we are at the end of our agenda unless there's any AOB that somebody would like to talk about. Bron, go ahead.

Bron Gondwana: I mentioned this in passing while we were doing the slides issue. Uh, we have two documents that have had a call for adoption done, and I believe the time for it has expired but they're still sitting unadopted in the data tracker. Um, what are we going to do about them?

Pete Resnick: Looking now.

Pete Resnick: Um, two calls for adoption. One was DNS, one was Best Practices. I remember I was talking about do we really need the DNS document and it was, the conclusion was we can adopt it and then decide later we don't need it. I'm fine with that. Um, and then the best, I, there was no objection to the BCP one at all. It's clear that we need it, we'll sort of edit it as we go as we develop advice and then put a more concerted effort into clean, cleaning it up and finalizing it after the spec document, is what I recalled. Does anybody have a different, have I got, have I got any of those wrong?

Richard Clayton: We, we were keen, uh, well, we were keen on the DKIM keys document because, uh, we are making changes and it's going to be much easier for an implementer to be able to look at a single document, uh, for this. Uh, and that single document can be the same for both DKIM1, which will be around for a little while, uh, and DKIM2, and quite possibly, because of the incentives here, uh, to keep the keys the same because that's the really hard part. Uh, uh, DKIM3 might well use the same set of keys, so having the keys split off in a separate document, uh, is going to be much simpler for people to have the right set of paper and not have to have marked up copies with changes. Um, the second, uh, of the, the business with Todd's document, the Best Practices, was that there was a feeling that, uh, uh, we would like to see it adopted because then there is a, uh, a much more defined way, uh, which Todd is keen on, I think he may be here and can speak for himself of course, but he was keen on, uh, having people start issuing, um, uh, pulls against it and issue opening issues and so forth, uh, so that, um, real progress was made on it and that was a much easier, much more formalized way of doing it within the working group, uh, if it was an adopted document, even if we didn't expect it to be fully finished for some time.

Pete Resnick: Right.

Pete Resnick: Um, so I've got a queue of four here, if you have but, two of you are visible to me right now and I'm not sure you're still in okay, they're going to hand up.

Okay.

Pete Resnick: Way, anything further? Oh, sorry, John was next, my, my mistake.

John Levine: That's okay.

Um, in principle I don't disagree, but for what we have done so far is essentially we, we have, we have adopted, um, algorithms that, that, that TLS has chosen. And for anybody who hasn't been paying attention, there is a, there is a, there is a, there is a, there is a DNSSEC efficiency hack that turns the NXDOMAIN into a no data. So it's not, you don't get an NXDOMAIN anymore. Now, to now to fix that they invented a pseudo-RR type called NXNAME, which a, which a, which a resolver is supposed to say, oh, I see an NXNAME and then it turns that back into, it turns that back into the, turns that back into the, into the correct NXDOMAIN to return to the client. So in theory, if people fully implemented 9824, the NXDOMAINs would look fine. The problem is that that in fact, that, that, in fact, while there are authoritative, there are definitely, um, DNS providers doing black lies, notably Cloudflare. The, the NXDOMAIN recovery, um, um, is not widespread. And I had a, a surreal discussion on the, on the, on the DNSOP list saying this is terrible, like if if you if you turn,

Pete Resnick: Can I pause you for a second, John? Are we talking about the same erratum?

John Levine: I think so. Isn't this the one that says check for NXNAME if you, if rather, when you're looking for NXDOMAIN?

Pete Resnick: No. No.

John Levine: Oh, never mind.

Um, the data hash, in particular, the data hash does not contain the body hash, that's done differently.

Anybody want to, uh, does anybody disagree with, let me put it this way, does anybody want to stop me from accepting that erratum? Or telling Andy to, anyway.

Okay. Okay, um, I will relay that message on the list to Andy and, uh, that'll be the end of this one. Um, John, Working Group is down the hall and to the right.

John Levine: Um, thank you for, thank you for your, your, your, your, your kind of ignoring the fact that, that, that I'm a confused old geezer, please continue.

Pete Resnick: Right there with you, John.

Murray Kucherawy: Oh, I see you've come here for an argument.

John Levine: Montreal.

Pete Resnick: Montreal. Um, so let me pull up a slide, uh, to share a slide. There's what Richard had to share. Which one is it? Oh, imaginary hops, right here.

Um, so, uh, why don't, uh, Richard, uh, Wei, why don't you talk to this while you're both here, and tell us what, what this is all about.

Richard Clayton: Okay, I'll, I'll start because I know what's on these slides, uh, and Wei can, uh, chip in.

Uh, do I press buttons for next slide? Uh, lost my buttons. Okay, yes, um,

Pete Resnick: I did it.

Richard Clayton: All right, thank you very much. Um, the, uh, and basically, Tobias in fact made two suggestion, a combined suggestion, one of which was the forward, which is what I'm describing here, and one of which is backwards, which after a lot of, uh, head-scratching and a certain amount of drinking of beer, uh, we're now all convinced, uh, is not necessary and it fixes a problem which nobody has. Uh, so let's ignore the second half of what Tobias, uh, suggested and just go with the first half. And essentially, the first signature that you put on, and I've got the ESP example here, uh, but the, uh, mailbox provider doing forwarding is, is, is, uh, essentially the same. It's just not at one and two, it's a higher numbered, uh, settings. Uh, then the, uh, the first DKIM2 signature, uh, has, uh, is signed by example.com, which is the, uh, the brand name, uh, and, uh, it says, uh, that the mail is coming from Alice at the, at the brand, and the receipt to is the actual real receipt to of the message, at the, at um, Google or Yahoo or, uh, wherever it may be, suitable flags for whatever, uh, flags the, uh, brand wishes to put on the, uh, message, uh, and then it says next D, um, now we may shorten that down to, uh, we will shorten that down to something else, uh, but this is, uh, for clarity here, it says and the next signature will be from esp.tld, the ESP. And then the next signature is indeed from, uh, the ESP, uh, and itRichard Clayton: says what the mail from and the receipt to will be for the, for the real SMTP conversation, whereby, where the ESP is going to send it out to the mailbox provider. Uh, but, uh, if you notice, the, uh, uh, basically, there is not alignment between the mail from receipt to because there's a, because it went magically went from the mailbox provider to the ESP, uh, sorry, sorry, went magically went from the brand name to the ESP, uh, but that's okay because the brand name said that was going to happen, uh, with that next D, uh, uh, tag in there.

So, Bron, you want to jump in here?

Richard Clayton: We can certainly take that out, that RT on i=1, it isn't doing anything. It was more for clarity, um, but, but it isn't doing anything.

Pete Resnick: Go ahead, Wei. I put myself in the queue for a question.

Pete Resnick: All right, Brian, you're up.

Richard Clayton: I, I believe that it is extendable and there's no problem with it being extended.

Brian Godiksen: Awesome.

Pete Resnick: Allen, go ahead.

Richard Clayton: It was Tobias the week before on the list.

Wei Chuang: Yeah, this, this was on the, the list.

Richard Clayton: I will check that there's nothing bad about removing the, the first RT, uh, since I'm always in favor of simplification.

Pete Resnick: Yep.

Bron?

Bron Gondwana: For what it's worth, I don't mind it being there, um, just that it can't be the one that you look at.

Pete Resnick: Right. It, it's, it's simply superfluous.

Bron Gondwana: Yeah. Yep.

Richard Clayton: We, we don't like superfluous, because if it said some, if it said aardvarks there, then they'd have to remove it. Right.

Pete Resnick: Right, try, try and come up with ways to leave people with foot guns, as they say.

Um, okay.

Good. Um, I, I like lack of screaming and yelling. Fine thing.

All right, um, then the next thing on our agenda,

Richard Clayton: And, and just to be clear, just to be clear, Pete, um, if you don't want to use this syntax, you don't have to.

A simplification.

Good.

Pete Resnick: Um, so all other business was on our hit parade, I, I believe, oh, Trent? Sorry, missed you.

Trent Adams: Yeah, sorry, I raised my hand and I didn't want to jump in, but it sounded like you were about to move on.

No, not to ask a stupid question, but I'm going to do it anyway.

If we're going to include the next D, and that's the override, why isn't that just what we do anyway? Why have the receipt to field at all? Why not always just put next domain equals?

Richard Clayton: Because you don't know what it will be because the, uh, the domain matching algorithm and the, uh, is, is fuzzy and the mail from receipt to is not fuzzy at all.

Pete Resnick: Yeah, Allen, go ahead.

Trent Adams: Fair enough, just wanted to bring it up.

Pete Resnick: Okay.

Allen Robinson: Well, also, for anti-replay, we want to assert that the RT value in the signature is equal to the receipt to command in the current SMTP transaction.

Pete Resnick: Oh, that again gets superfluous in the normal case because it better the heck match the RT, right?

Allen Robinson: Um, yeah, you, you would have the same type of alignment expectations, but you wouldn't have to parse the address to figure out what's supposed to be there.

Richard Clayton: The fuzziness is the issue here.

Allen Robinson: So, yeah, I, I don't think it's worth having it, but we could.

Pete Resnick: Bron, you want to make an argument one way or the other?

Bron Gondwana: Yeah, specifically to answer Trent's question explicitly, the purpose of next D is to say the next domain is me as well, I, this is a trust relationship between these two domains. And the purpose of all the other relationships is this is not a trust relationship between these two domains. I'm sending this across the internet to someone I don't know anything about other than that they have this receipt to email address. So they're two distinct cases, and we don't really want to conflate them. If you see next D, that should be, this is me signing again, or this is someone I trust signing again, and, and we have a relationship.

Pete Resnick: All right, then moving right along, um, your next slide is, was your first thing for all other business, right Richard?

Richard Clayton: Correct.

Pete Resnick: All right. There's your next slide. Please ask the working group what you will.

Richard Clayton: Right. Okay.

Um, let us suppose you have an email which, uh, comes through you, uh, and then you send it on to somebody else, and they send it on to somebody else, and they send it back to you. And it goes, so it's going round in a bit of a circle, not necessarily a true circle, but to, uh, multiple places on your domain, uh, but possibly the, but possibly the same one. Uh, and then you decide to, and somebody decides to generate a bounce message. Um, it may be very complicated for you to work out whether or not it is being bounced back to you, uh, from hop 7 or from hop, or from hop 4. Uh, and, what you do with the mail might be different depending on who it's been bounced back from. Uh, and, what you concluded about the bounce would be, uh, simpler. So, the simplest thing in order to fix this, is to say that when you get a, uh, a DSN given to you, uh, and you are deciding that you are going to pass that DSN back along the chain to the person, uh, who gave you the mail in the first place, then if you strip out of part 3 of the DSN, the headers which you have, the modifications which you have made to the message, uh, and then generate the DSN, uh, as if it, you had never forwarded it to anybody else at all, this is kind of a good thing from a privacy point of view, and it's a spectacularly good thing in terms of complexity as to worrying about whether or not the mail is coming back, uh, through multiple hops and which hop, uh, you, if you appear at multiple places in the, uh, in the chain of signatures, uh, then which of these are you meant to be dealing with just at the moment. So, the, the very fast, uh, path, uh, let us, uh, check things, uh, for the, uh, for the receiver is unaffected by this. It's only when you start looking at the chain of custody that you see the next D and so forth. And, basically, this avoids inventing an imaginary address at the ESP, which, uh, the mail was sent to in order to show a chain of custody because that, that just never happened, and inventing such an email address will just confuse everybody.

Pete Resnick: Bron, you have your hand up. And then Dave had a comment in the room that I'm trying to parse, yep.

Um, anybody else?

Comments on any of these.

And I'll take Bron out of the queue.

Dave Crocker: My audio's working, but I, I figured what I wrote probably clarified it enough.

Pete Resnick: Okay.

Pete Resnick: Yep. I hear you.

Pete Resnick: Very good.

But,

Pete Resnick: Ack, yeah.

All right. Well, um, then I will snatch the mic from you and hand it over to Bron to talk about, uh, uh, his issue, which I, uh, failed to do earlier.

Bron Gondwana: Thank you. Murray, I sent you some slides immediately before this meeting started, sorry for the very lateness. Have you been able to upload them?

Murray Kucherawy: I uploaded them before the meeting started.

Bron Gondwana: Sweet.

Murray Kucherawy: So they should be in the set there.

Bron Gondwana: So I guess if I ask for slide control, then I should be able to present them.

They are not present in the view I can see. I only have Chair slides and AOB Richard Clayton.

Pete Resnick: Right, they weren't in the tracker. They are there now. Let see if the, yes, they're available through MeetEcho now. You still have control?

Bron Gondwana: Uh, I'm requesting it again.

Pete Resnick: Okay, here it comes.

Bron Gondwana: Sweet, thank you.

Pete Resnick: Yep.

Bron Gondwana: All right. So this was something that I, I guess I spoke about on the fly during the last call, late at ridiculously late at night for me over in Europe. And I thought I should write it up a bit more properly so that we can talk about it this time. I don't know if we want to go ahead with it, but there are two things. The first is hashing of X-headers. There's a proposal for allowing you to make your X-headers unfakeable. And so, I proposed a new field, Message-X-Headers, which has a list of the header names that are being hashed, and a SHA-256 of those header names. Yeah, meh, is is ideal. In exactly the same shape, but you have to name the specific headers that are on there, and otherwise you would use the, the same calculation, start from the bottom, sort them alphabetically. And I guess maybe require them alphabetically there too because I've put them the other way around, but we could specify exactly how this is done. The important thing is that if you mention it in this thing, and we can call it whatever we like, the important thing is that you add a recipe for that X-header into the header recipes, and then the following rule from that is that if you create a new message instance, you must include, if you change any X-header that was mentioned in a previous message instance recipe, then you need to add a recipe for the change that you make to that header from there on. You can't touch any header that's mentioned in a previous recipe without giving a recipe for it. And that's the only, that's the only change. That then allows you to have reliable hashes for any header that's not already hashed, but you just have to check it in the previous message instances and you have to make sure you create recipes if you change it.

Alan?

Allen Robinson: Okay.

Bron Gondwana: Cool. Um, I think that's a better solution.

True. Um, but I think, I think the as a, as an escape valve, it gives us an escape valve. And then you would explicitly say this is, this is also signed. On the other hand, that adds complexity.

Pete?

I, I actually, Richard first, then Pete.

I'm sure Richard is going to say I hate the idea and we shouldn't do it, which is a perfect...

Bron Gondwana: That seems perfectly reasonable to me. I just wanted to write up what the proposal was, and already Allen has a better proposal which we also shouldn't do.

Pete.

Pete Resnick: So, John asks in the room who wants this, and um, at least Pete, um, in addition to Vittorio.

Bron Gondwana: To do a poll? Yeah, we'll run a poll of the room and see what people think. Let's see where the, where the sense is.

Pete Resnick: I'm happy to. Um, I can do up a little poll. And I'm thinking,

Bron Gondwana: We might as well, we've got the tool, might as well. And it's, it's not a hill that I care to die on either way, but um, yeah, would be good to see.

Pete Resnick: Yep, um, so I will say, "Ability to sign particular X-dash: Worth it? Yes. Not worth it? No." How's that?

Bron Gondwana: Yeah.

Pete Resnick: I'll stay out of the poll.

Pete Resnick: And okay, I mean, is that everybody? How many do we have here today? 13.

That's close to everybody.

Bron Gondwana: It's a, it's a strong but not, not unanimous, but a few didn't vote. There's two other people who voted yes.

Pete Resnick: That's right, and, and, so, so, do the yeses want to say something since they are clearly in the minority end of this?

Alan, are you a yes? Wei, are you a yes?

Allen Robinson: Uh, I mean, maybe we are both the yeses, uh,

Richard Clayton: I didn't push the button, so.

Pete Resnick: Wei?

Wei Chuang: Yeah, plus one to what Alan said. Um, basically, I don't, sure, these things are in the eyes of some, abhorrent and problematic, but I think they exist, and they exist for a reason, and they exist in many parties introducing them, including us. So, having some ability to be able to protect them, I think, is actually an important capability, um, just because they look grotesque, they, of course, do serve some important functionality in the email ecosystem, and, uh, we want that sort of capability. So, so yeah, however it is to be done, uh, and otherwise we, you know, there's a likelihood of also just simply ad hoc solutions that become, uh, problematic in the, in the long run too.

Pete Resnick: Murray, I presume with hat off?

Murray Kucherawy: Yes. Yes, with hat off. Um, just for Wei, you say they're important. You introducing, sorry, you are introducing X-fields into the ecosystem that you say are important, they are important to whom? Besides you.

Wei Chuang: Uh, they're important to us. Um, I think, the, they're not meant to be interoperable, otherwise, of course, you know, the, the right thing to do would be to create a header and define it. But I think, uh, you know, a lot of these sort of proprietary headers exist to, uh, provide information through the delivery path, uh, and then basically provide information that's, that's necessary for the deliverability of messages. Um, obviously, these things are important, uh, they get attacked and then, it is, uh, exercise in how do, how do we do this in the most efficient way that, uh, protects those headers.

Murray Kucherawy: So, so, just, I'm going to focus on something you said. They're, they're useful to the, you used the word path. I'm trying to remember exactly. But to the delivery path, to the handling path. That means, I take that to mean, other operators on the handling path will find them useful. Then you need interoperability, now it needs standardization, X is not appropriate for that. That's, in my view, at least. So, I don't understand, there's a disconnect somewhere and I'm trying to get to the bottom of it.

Wei Chuang: Right. Right. So, many, uh, participants in the mail system may send traffic that ultimately comes back to them, right? And then, so, in those scenarios, uh, you know, those, those headers are intended for communication between those, those parts of the, you know, system where it's, it's basically the same platform that's used again, and they're not meant to, you know, interoperate in the traditional sense of, you know, things that are meant to be out there and open. Hence, I used the word proprietary. Right? But, they do have an impact on the, in many cases, on the deliverability of messages.

Murray Kucherawy: So, um, X is not the important part, right? It's, it's the fact that it's yours.

Wei Chuang: Right.

Murray Kucherawy: So, you could go google-dash something and then sign that, and still put whatever you want in there. It doesn't have to be X-dash. So, um, I think using, if we can separate those two things, X being, you know, universally experimental and having a lot of history and a lot of baggage associated with it, and you having some, some header field you want to attach that if it boomerangs to you, you're sure has not been modified and possibly contains useful forensic information for you.

Wei Chuang: Right. Right. So, the, that is one of the options is basically, and I think John, John, John Levine suggested that and then, so, basically, we do such a thing like that. Um, and, that's fine if that's the ultimate path that has to, you know, that we have to go.

Murray Kucherawy: That, I mean, you can also publish your own standards about that. I mean, you could do it with the, with the IETF, but, um, you can also just have a web page someplace that says google-X means this, google-Y means that and we sign these things, etc., etc. Um, the, it's up to you how you handle it. I, I, I'm, I'm just trying to get to the bottom of the, how these get used and, and does the standard need to accommodate them. So thanks, that helps.

Pete Resnick: Richard, tell me why I'm a, a, a, blockheaded ignoramus.

Richard Clayton: Basically, this notion that, that this notion that X-headers are suddenly, community suddenly discovers that they're useful, uh, and starts using them for doing X, Y, and Z. Um, all examples people have attempted to produce so far have turned out to be, uh, inventions in their own mind because there's no, uh, because I spent some time, uh, generating evidence that they just, not, these headers are not occurring at any scale that they'd be useful to anybody, that's the first thing. Secondly, in such a case, you have to wait until the person who is putting the X-headers on thinks that it is useful, uh, for them to actually sign it. Um, now, and they may not wish to sign it because one of the reasons that, what, the, the only reason that we excluded X-headers, uh, from this is because, uh, large systems told us that, uh, they were pushing email around here, there, and everywhere, going through all sorts of systems who are always complicated, was very hard to predict exactly what would happen to them, uh, and X-headers being added left, right, and center and trying to, uh, be able to produce the recipes in order to show which X-headers were going to be added to a particular message was far too complicated to get right and would delay the implementation of DKIM2, uh, by some considerable time. And so we said, well actually X-headers don't mean anything outside of your boundary, uh, and, uh, let's move on. Now, yes, there are headers which are useful outside your boundary, at least they're useful to you when they come back inside your boundary, uh, and, uh, at day job, uh, we, we produce one of these, but what we do is we don't rely on, uh, on this fancy new signing and so forth. What we do, uh, is we encrypt the content because in fact the content is quite sensitive and full of PII, uh, and, um, uh, we sign the, the header so that if somebody attempts to forge it, we know that, uh, this has happened, uh, and that, um, it is extremely useful to our customer care people, uh, because they can tell when somebody is being framed for sending bad mail or whatever because we can decrypt this special header, uh, and we can see, uh, all of the, uh, detail that we need about the handling of this, uh, how this, uh, message was handled and processed and so forth internally and in particular who actually sent it, rather than, uh, what the from line of something which may be forged and, um, being thrown around and so forth might tell you. So, uh, that is how we handle these headers and we put an X in front of it so that nobody thinks that it, because that was often seen as being the, uh, the friendly thing to do so that people would know that it, it was not going to be meaningful to them.

Pete Resnick: Bron, do, do you want to jump in on this or do you want to further berate me for, for forgetting about your agenda item? And, and, uh, we'll get back to...

So, in summary, I agree with Richard, no null...

Pete Resnick: Yep. I hear you.

Pete Resnick: Very good.

But,

Pete Resnick: Ack, yeah.

All right. Well, um, then I will snatch the mic from you and hand it over to Bron to talk about, uh, uh, his issue, which I, uh, failed to do earlier.

Bron Gondwana: Thank you. Murray, I sent you some slides immediately before this meeting started, sorry for the very lateness. Have you been able to upload them?

Murray Kucherawy: I uploaded them before the meeting started.

Bron Gondwana: Sweet.

Murray Kucherawy: So they should be in the set there.

Bron Gondwana: So I guess if I ask for slide control, then I should be able to present them.

They are not present in the view I can see. I only have Chair slides and AOB Richard Clayton.

Pete Resnick: Right, they weren't in the tracker. They are there now. Let see if the, yes, they're available through MeetEcho now. You still have control?

Bron Gondwana: Uh, I'm requesting it again.

Pete Resnick: Okay, here it comes.

Bron Gondwana: Sweet, thank you.

Pete Resnick: Yep.

Bron Gondwana: All right. So this was something that I, I guess I spoke about on the fly during the last call, late at ridiculously late at night for me over in Europe. And I thought I should write it up a bit more properly so that we can talk about it this time. I don't know if we want to go ahead with it, but there are two things. The first is hashing of X-headers. There's a proposal for allowing you to make your X-headers unfakeable. And so, I proposed a new field, Message-X-Headers, which has a list of the header names that are being hashed, and a SHA-256 of those header names. Yeah, meh, is is ideal. In exactly the same shape, but you have to name the specific headers that are on there, and otherwise you would use the, the same calculation, start from the bottom, sort them alphabetically. And I guess maybe require them alphabetically there too because I've put them the other way around, but we could specify exactly how this is done. The important thing is that if you mention it in this thing, and we can call it whatever we like, the important thing is that you add a recipe for that X-header into the header recipes, and then the following rule from that is that if you create a new message instance, you must include, if you change any X-header that was mentioned in a previous message instance recipe, then you need to add a recipe for the change that you make to that header from there on. You can't touch any header that's mentioned in a previous recipe without giving a recipe for it. And that's the only, that's the only change. That then allows you to have reliable hashes for any header that's not already hashed, but you just have to check it in the previous message instances and you have to make sure you create recipes if you change it.

Pete Resnick: Okay, um,

Pete Resnick: does that setup, setup a next step for us here, Andy? Like, should, one of the suggestions that was going on in the, in the chat was, um, we should approach, uh, CFRG, at least ask the question, get it on their radar, um, get them thinking about it. But I don't, I don't know if that, what action would come out of that for us necessarily.

Andy: (Andrew Melnikov) Well, well, again, I, I think we need to clearly define what the question is, right? That, that's what I meant by threat model. We we need, we need to, we need to say, here, here is the threat we see, and, um, let us know whether it's, it's valid for post-quantum or not. And then we can ask the next question, whether, what post-quantum we want, what we want to do about it.

Pete Resnick: Okay.

Pete Resnick: Um, so I guess, Wei, can, are you in a position to write, do you feel like you know, have heard enough of, to write what we think the problem might be, like, in a form that we would send over to CFRG for an opinion?

Wei Chuang: Um, I, I can collaborate with folks that, uh, are more versed in what that future is, I guess. But, I mean, put that out into the working group mailing list, and then basically, come up with something that could be sent off to CFRG or whomever the right, uh, recipient over in that part of the world is.

Pete Resnick: Yeah, I mean, we can, the chairs can really do the actual liaison, I just want to form the question in a way that, I mean, this is not an area of my exp- expertise, so I shouldn't do it. But, um, I'm happy to, like, be the one that's the, that's the liaison once we have the actual question formed.

Wei Chuang: Right. Thanks.

Pete Resnick: Anything else on this topic or any other? We are at the end of our agenda.

Okay. Hearing nothing else. Uh, we do not have enough we aren't able to give enough lead time, I think, in order to have another um, interim before Vienna. And it probably doesn't make sense to do that anyway, because we're so close in. So, uh, the next meeting will be in Vienna. I think we have requested a two-hour session. The agenda has not appeared yet, so I couldn't tell you which day or whether we're morning or evening or what, um, but, plan is for, go ahead Andy.

Andy: (Andrew Melnikov) Um, yeah, so, speaking of scheduling in Vienna, um, there are likely going to be a lot of AI BOFs, um, at least three. Uh, I'm just curious, would people be, uh, upset if this was, so, essentially we have this huge conflict resolution thing we have to do with the, with the meeting in, in Vienna, and I'm curious if anyone would be like, uh, tragically upset if they were, weren't able to attend an AI BOF, um, because of this, because of DKIM. So,

Pete Resnick: I'm just going to go. You can schedule however you want. I'm just kidding. Um, um, how many, you, there, you said there, there's a, there's a bunch of them, so we're going to be possibly up against one of them or against up against several of them?

Andy: (Andrew Melnikov) Uh, it's likely we'll up- be up against one, um, at least, but there, there's at least three coming up. So,

Pete Resnick: Okay.

Pete Resnick: Um, I mean, we can survive. I, I know how this, I know that scheduling nightmare that the IESG goes through, so, uh, personally I can survive. I will try to get to those other things, but, I mean, I'm probably going to have other conflicts to deal with as well. Anyone else have a, a view on this?

Pete Resnick: Um, doesn't sound like it's a big deal at the moment.

Andy: (Andrew Melnikov) As Bron, we will use AI to schedule, thank you. Great, thanks everyone.

Pete Resnick: Um, anything further? Peter, you, are you safe where you are?

Okay. Um, hearing nothing else, I can give you all 13 minutes back of your time. Thank you, Bron, for taking copious notes. Uh, we'll convert that into minutes and get those posted. I think we, I still owe, I still owe for the last interim and I think Pete still owes for one other meeting, so um, we'll, we'll get our, we'll get our, we'll get through our backlog and get those posted, but um, uh, we'll see you all in Vienna. Thank you for coming.