Markdown Version

Session Date/Time: 20 Mar 2026 01:00

Seth Blank: People who are running up the number of investigations, quote-unquote investigations. Like, switching the MAC address every day on purpose. Yep. I know. What I find when I go to meetings in general... I find it puzzling all the places that US things are geo-fenced, where I can't get to the grocery store or something. And the other is that things that I have to turn on the VPN to make them work, and things that I have to turn off the VPN to make them work. So I'm constantly bouncing my VPN on and off because some website that has no reason to care whether I'm on a VPN won't work if I'm on a VPN.

Well, my illustrious co-chair has yet to wake up or has fallen asleep too early. One or the other.

Murray Kucherawy: Murray!

Seth Blank: So we will at least get started with the... It's only 6:00 p.m. his time. I know, he should be fine. But anyway, we'll get started with at least the administrative stuff and move on from there.

Welcome to DKIM. Smallest room in the meeting. Yes, I've been asking for many years to give us a square table or, you know, open rectangle or whatever. And one of these days we will get one for these kinds of meetings. It feels very nice compared to the big room. Yes. I can actually understand.

So, Note Well. You all in the room know this, but this is just a reminder for everyone that you are participating as per IETF policies and procedures. So please do check out the assorted guidelines for conduct, anti-harassment policy and procedures, the procedures and policies regarding intellectual property rights, the Internet Standards process in RFC 2026, and the working group guidelines. And of course, the privacy statements. This session is being recorded, so if you get up to the mic, everybody gets to hear you and see your smiling face out in Internet land. They're trying to AI fake you. If you have any questions, feel free to ask.

A couple of quick tips. Hopefully you've been participating all week. But please do sign into the Data Tracker. There was a QR code but it's now used up all the screens. But please sign into the Meetecho room because we'll use that for queueing whether you're remote or in the room. Please keep your audio and video off if you're not using it. And for the folks in the onsite version, please do not use audio or video. Use a headset if you are a remote participant to cut down on echo if you can. But so far we've had pretty good luck with echo cancellation. And please, when you get up to the mic in the room, state your name just in case people didn't see you in the queue.

So, the agenda is out on the Data Tracker. The information on Meetecho is also out on the IETF website. And any technical assistance, there is a reporting page out there if you're having trouble during the session. So here is our agenda. Nothing too exciting. The agenda slide, as Harald would have us say. We're going through some of the adminstrivia now. Then we're going to have a discussion of the newly adopted draft-clayton-dkim-dkim2-spec document. We will go through issues with the header format in JSON. We will talk about the whether-to-sign-all-headers issue, which is the ongoing discussion. The envelope alignment issue of whether that is in the spec. The header field alignments if we're going to have those. And so Richard prepared some slides. Bron and/or Richard and/or Wei, if he's in the room, will be speaking to those. And we will have discussion on the document. Then at the end, we'll have a quick little question from the Chairs about upcoming interims and then all other business if anybody has anything else. Any changes to the agenda? Anybody want to sneak something in beforehand? Yeah, Bron.

Bron Gondwana: I stuck myself in the queue here. I think we should go through the rest of the documents that are adopted or due for adoption and just go through and see what the status of each of them is and what the plans are.

Seth Blank: Yeah, that seems reasonable. I'll get the document page up. Okay. So, good. So we've done our Note Well and meeting tips. We've done our agenda bash. The chairs are going to use the recording, the transcript, and Ecker's meeting minutes maker, although I've already found that I have to edit things because, you know, AI is AI. But if you would like to log in to the note-taker page, there's a little pencil icon dead center in the onsite tool. If you want to take some notes for the rest of us that you think are important, that's always welcome and we can incorporate those. But no requirement that we'll do a minutes taker in the room.

And a quick note on the chairing stuff. Murray and I, at the end of last year and beginning of this year, have been a little absent for assorted reasons. And we are now back in business. We have also noticed that—and I think this is our general nature, the two of us—we've been a little light-touch on the mailing list. And the past at least few weeks we've noticed that things seem to be circling a little, that we come back to the same things a few times and it's drifting. So our plan is to be on the list, identifying what we see as open issues, to kind of direct discussion and try and declare consensus more quickly. And you are of course, as always, welcome to push back and say, "Whoa, guys, I think you blew this one" or "I think this one needs a little more discussion." That's perfectly welcome. But we are going to try and at least pay a little more attention to the list and sort of drive things a little forward so things happen a little more quickly. Any questions about that? Cool.

Alright. So we were going to switch to draft-clayton-dkim-dkim2-spec, but let's first go take a quick look at the Data Tracker. Let's see if I can share a screen. This will be exciting. How do I share a screen from the... can I share a screen from the in-room tool? I can share slides. I do not see a way to share a screen. Am I brain damaged? Someone help me.

Bron Gondwana: Under more tools?

Seth Blank: No.

Bron Gondwana: There's request screen share button down the bottom for me. It says Non-Slide.

Seth Blank: It's to the left of the share slides. I don't have one as chair. Someone else... Bron, you want to share the Data Tracker page?

Bron Gondwana: I've sent a request.

Seth Blank: Yes. And I will agree to that. There you go.

Bron Gondwana: I think that... there we go. For mine, I can only ask to share slides, not the screen. Bron did it. Yes, I do want to share my screen. Allow share window. Is that it? Hey! That's a little too exciting.

Seth Blank: Alright. So right now what we've got—I'm going to move my mic over here so I can read the screen—right now what we've got is draft-clayton-dkim-dkim2-spec is the adopted document that we're going to be working from. draft-ietf-dkim-dkim2-header is what we had adopted, right? And as a working group document along with the motivation document. So the proposal on the list was basically to drop draft-ietf-dkim-dkim2-header because that's what got folded into draft-clayton-dkim-dkim2-spec. Does anyone have any concerns about that? Anybody remote? Everybody okay with that? Shouldn't draft-clayton-dkim-dkim2-spec be renamed? Yes, it will be renamed, Jim. The next rev will, you know, when Richard gets a chance to upload a new version after this meeting, it'll go ahead and be renamed draft-ietf-dkim-dkim2. Any other concerns? Good. We will do that.

We will keep DKIM2 - signing the source and destination of every email (draft-ietf-dkim-dkim2-motivation) around, I believe, because we were talking about whether that was going to end up being a BCP, a sort of applicability statement, etc. and so forth. And it can kind of be a dumping ground for design stuff. And if we decide to ditch it in the end, I've got no issue with that. But we'll go ahead and get rid of the header document since all that should be in the spec document. Bron, go ahead.

Bron Gondwana: I think I probably should rev that fairly soon because it's going to expire in a bit. So I will have a look through it and see if there's anything that's blatantly wrong now and propose changes if so. Otherwise, I'll just rev it with a new version and no changes.

Seth Blank: That sounds fine. Barry.

Barry Leiba: Well, I think you shouldn't bother. I don't think there's anything nasty about expired documents if we're not working on them actively. It doesn't matter. If you're not going to change it, there's no reason to rev it. The reason I got up is to ask you to scroll down to the related drafts. And I note that three of them are labeled candidate for working group adoption. So we should clean that up.

Seth Blank: Yeah. So the draft-brotman-dkim-feedback-loops is in there because it was from ancient DKIM and so we should undo that and I will do that. The draft-nermozo-dkim-dmarc-public-suffix-list, I believe we had marked as candidate back in the day when we were just looking at what are we doing, so I can undo that. And draft-mail-version... did a call for adoption go out on that yet?

Bron Gondwana: Yes, but that has also been rolled into spec. That one got some renames during the last IETF, so that's in a messy state. That one should just go away.

Seth Blank: Okay, so we'll mark all three of those as working group dead or whatever the magic label is.

Bron Gondwana: I believe Brotman is actually... it's a 2026 document. I believe that is one that we're planning to keep, that describes interactions of DKIM2 with feedback loops.

Seth Blank: Really?

Bron Gondwana: I think so, yes. It was revved in January.

Seth Blank: We'll... then we'll do a call for adoption at some point. But let me... I have not looked at that document since the working group began, so let me give that a look and Murray and I will figure out what to do with draft-brotman-dkim-feedback-loops.

Bron Gondwana: Cool. And I believe DKIM BCP (draft-ietf-dkim-bcp) and DKIM DNS (draft-ietf-dkim-dns) are also both intended to be candidates for adoption. They just describe... the BCP describes how to use it rather than how it works, and DNS describes the DNS key entries and how they work.

Seth Blank: Okay, so those two you're saying should be called for adoption at some point. Alright.

Barry Leiba: Right, but the other, the draft-nermozo-dkim-dmarc-public-suffix-list and draft-latimer-dkim-intermediate-signing ones...

Seth Blank: Well, Latimer is just an idea exists.

Barry Leiba: Right, but what I'm saying is should they continue to be listed on the related drafts?

Seth Blank: They're auto-listed. But they can be eliminated. But I'm fine leaving other people's proposals there until they expire. Okay. Richard, go ahead.

Richard Clayton: I'm going to say pretty much what Bron said, which is, first of all, the DKIM keys one, which is Wei's draft, is required because we want to deprecate some of the features of keys. And it felt more useful to make a separate draft to describe the DKIM keys because they are common between DKIM1 and DKIM2. And writing the spec to say see DKIM1 spec only for this section about the keys and ignore everything else didn't seem particularly helpful to implementers going forward because they might get confused. Plus we want to deprecate some of the features which are in the DKIM1 RFC. So that's the first thing. The Todd's thing is absolutely required because it contains all of the helpful advice to people which I have ruthlessly eliminated from the spec on the basis that it is not a specification issue, it is good advice to people which they probably ought to follow, but it is not an interworking issue if they don't, in quite the same way. And Alex's, the Brotman one, I think probably needs to be revved in such a way as to tie in properly with the notion of feedback loops as envisaged in DKIM2, where you set flags saying "I would like feedback, please." And Alex was trying to do that independently of DKIM2. So it's kind of a DKIM1-era thing. Equally, depending on the timelines on which DKIM2 is widely adopted, then it may still be relevant for this working group to consider.

Seth Blank: So, on the Brotman one, I will talk to him about timing of things. Clearly we want to, you know, focus working group time on the core document. The BCP stuff obviously, or whatever we're going to end up calling it, is going to come at some point, although I would be happy for that work to continue sort of parallel, but not the center of our conversation on the list.

Richard Clayton: Yes, good. To be helpful, there's also a separate RFC draft which has been prepared to do with aggregate reporting of email delivery, which has not yet found a home anywhere in the IETF. It's very recent. And the Brotman thing fits with that. So if that finds a home which is not DKIM but is somewhere else, then it's quite possible the Brotman draft would go there naturally.

Seth Blank: Got it. Barry.

Barry Leiba: Just a comment on the BCP thing. This is Barry. I would hope that what happens is that as discussion goes on the other documents and something comes up that ought to be flagged for the BCP, Todd just puts it in there and we don't discuss it, but it's just set aside for when the time comes.

Seth Blank: Right. And yeah, I believe on most of the other documents... yeah, you could turn that off now, Bron. Okay, thank you. I guess I could have eliminated it, but yeah, I think I have no issue with that sort of being the constantly open and revisited document. Bron, is that a hand or just leftover in the queue?

Bron Gondwana: Yes, it is a finger. No, it's a hand. I guess this is a question maybe for the Chairs, whether BCP should be adopted in a working group document or be an individual document. Obviously the design—how to use it—will influence the design, and vice versa. Whether we should be adopting it and have it be controlled by the working group rather than Todd personally.

Seth Blank: I absolutely think that the BCP should be a working group document, we should put it out for adoption. Because it will be a dumping ground for us. And sooner rather than later. Yeah, no issue whatsoever. So I will have that on my list. I'm watching it go into the transcript as we speak. Todd, go ahead.

Todd Herr: Yeah, I just wanted to assuage Barry's fears and confirm that I will try to make his hopes come true and capture things in the document as they come up.

Seth Blank: They were not fears. Alright, good enough. Alright, then with that, let's just go on to Richard's document. Let me go ahead and share the slides. And I believe I can grant control to Richard. How do I do that? Passed slide control? Yes. All right. And we don't see... do we see the slides? It's fine in the tool, but in the room we get two Richards and no... Yeah, so let me drop a message to Meetecho.

I'm just going to Slack them. Oh you got it? Okay. Yes. Somehow they are interestingly plugged such that we cannot see the slides and your smiling face at the same time. And even if you turned off video, we'll see a big square that says Richard on it and not the slides. So let's give them just a second if we will. And it was, so I don't know what changed. It was working. But hopefully they will get back to us. Oh, it does look... Oh, so you all in remote land can see the slides. Okay, well that's glad... I'm glad to know that. So it's just in the room. Wait, is everybody logged in such that they can see the slides on their own screens in the room? Okay. Then Richard, go ahead and in the meantime we'll try and get things fixed.

Richard Clayton: Okay. Right. [Current thinking on DKIM2 (Richard Clayton): https://datatracker.ietf.org/meeting/125/materials/slides-125-dkim-current-thinking-on-dkim2-richard-clayton-00]

Message instance, as we all remember, is a tag-value field. This slide is just remembering what the tags are. It has a V equals which says the originator has V equals one. If you change a message as it goes through from one place to another, then you stick in a new message instance header field and the next one is labeled V equals two, V equals three, etc. etc. It contains two things. It contains the recipes, which allow you to go back to previous versions of the message. And the recipes are some JSON which is then base64 encoded and then dropped into the message instance header field. And then you have the hashes for the... with the hash name and then the header hash and the body hash.

Now, this, the current thinking is if you look, read the 08 version of the specification, it says that the hashes should be in a JSON structure. And because I am an incompetent person, I made a real pig's ear of defining that JSON structure. However, whilst we were trying to sort out what the specification should have looked like, John Levine very helpfully pointed out to us that there was absolutely no need for this to be in JSON at all. Some of the other things are... there's good reason for them to be in JSON. But there's no need for the hashes to be in JSON. So what 09, or its new name 00 or whatever is going to be, will say, "Well, forget the JSON for the hashes," and it will just put in an H equals algorithm colon, the base64, the body hash, the base64 of the header hash, probably, I think in the other order I wrote down in the 09 this morning. And then if you have multiple hashes, then you put a comma and then you put another triple, etc. This change seems like a no-brainer. We made it too complicated by using the JSON, so going back to something which fits straightforwardly into a tag-value field and is human-readable seems very straightforward.

I stuck on this slide because it didn't really fit anywhere else, that we have managed to define message instance without any versioning scheme. Now we've thought about this and we've decided that this is just fine. Almost every time anybody has tried to do versioning schemes in email, they've been stuck on version one. And it's stayed as version one and nobody has had a decent plan how to change it to version two. This is why the DKIM, the original thing we came along with for DKIM just said "This is DKIM2" and it says DKIM2 in the header field name. And if you want to build a new one, then you'll write DKIM3 in the header field name and that will work just fine for versioning. You know, if you look at MIME headers, it says it's a V1 MIME header, but nobody's ever tried to do a V2 MIME because we just have no idea how to do this and nobody thinks it will work and everybody thinks that it will make a mess of it. So there isn't any versioning in message instance. If people want to define a new version, new type of message instance down the line, then they are going to have to either make it up as compatible or they're going to have to give it a new name. And that's just fine by me. But I draw it to the attention of the working group just because we've been talking about it, we've come to the conclusion that we're just fine with there being no versioning, but if people want versioning then we could add it. There's no real difficulty in adding it, but we think it's just a waste of space. I'll stop there in case anybody wants to chip in.

Seth Blank: Yes, please. We'll go topic by topic. So the mic is open. Please jump in if you would like to. Bron, you're up first.

Bron Gondwana: I like this. I've implemented it this morning and it is interoperating just fine on my test cases. The question of what is in the recipe I assume might come up later because that's something that we've been discussing—what's compatible. And the discussion on the chat about calling it MI rather than V, which I think we probably should bike-shed that at some point. Let's not do that in the room. One extra character is fine. I'm happy to bike-shed it at some point in the list. But yeah, I think we can deal with that at some point.

Seth Blank: Anybody else have concerns on... Barry, go ahead.

Barry Leiba: No, just adjusting the microphone.

Seth Blank: Anybody else want to jump in? All right, go ahead to your next slide. People may come back to this.

Richard Clayton: Okay. This one will run and run. This is the issue on what headers should be signed. The current version of the draft, and in fact every version of my specification draft, has said that you sign every header which you find in the email in your hand, apart from:

We wish to exclude X-hyphen headers. The reason we want to exclude these is because they are widely used by mail systems for their own internal purposes, and people add them left, right, and center. And being told that the mail system added them is not a very useful thing for anybody to know, and nobody is going to do anything different with the incoming email, the fact that other people have stuck their own proprietary headers into it. So we exclude X-hyphen-star. And there won't be any new real headers with X-hyphen-star because Dave Crocker years ago pointed out that all of these things where you defined an X-hyphen-star and then tried to standardize it thereafter all went pear-shaped because everybody got locked into the old version. So there ain't going to be any more X-hyphens, therefore all the X-hyphens are all internal, and so excluding them simplifies the life for many mail systems.

We want to exclude DKIM-signature and Arc-hyphen so that you can sign DKIM1, you can ARC sign and so forth in any order with DKIM2 and you're not stuck doing one before the other. Potentially you could DKIM2 sign and then DKIM1 sign saying that you were explicitly signing a DKIM2 header, but that would be moderately insane, so I don't think we need to worry about that. Now, this design is really easy for people to understand. And the really key thing for me is that people cannot make poor choices about which headers they sign. Because we see out in the real world people making very poor choices about which headers that they actually do sign. As a result of which there are potential at least security issues so that email which is DKIM1 signed can be misinterpreted and the user will see something which they're told "this is authentic and it comes from the right place," etc. etc., but it is not what the person actually sent.

Also, not putting in the actual headers which are signed keeps the size of everything down because we don't have a long list. A line and a half in most real cases, more if you wanted to be pedantic about what you were signing or saying was absent. So it's really very straightforward to do this. The people that don't like this seem to think that they have no idea what their mail system does and they have no idea what headers will be added and they think there'll be a large amount of bookkeeping involved in keeping track of what they have added. I don't run other people's systems. The systems I run and look after, we have a very, very, very clear idea what headers we add and when and why. So I don't see why they're not as organized as we are, but there you go.

The final thing is that the actual draft at the moment says that in order to avoid the over-signing, which we have in DKIM1 whereby you name header fields twice in order to stop people adding them, we concatenate them all together. And we say that we concatenate... the spec says that they're concatenated together in top-down, so the first one first, second one second, and so forth from the top of the email message. That sounds very sensible except Bron points out that since the recipes work from the bottom up for headers, for reasons which we'll discuss when we get there, then maybe these should be done bottom-up as well. I think it just slightly complicates the code, but it's no big deal either way, so it's really what people prefer and what people find natural and, in the limit, I guess what is easier to write down and have people understand when they're trying to do an implementation. That is my thoughts on that.

Seth Blank: All right. So I put myself in the queue. And so hat off, but this is a question more than an opinion. Leaving aside the concern—or maybe it includes the concern—that the opponents have about keeping track of what they've added. Right now the spec seems to require the message instance stuff. That you're going to have to, if you're implementing DKIM2, go ahead and describe any changes you make to a message. And I'm not clear how the opponents of this are going to do that and still be able to ignore the X-dash or whatever else they're inserting along the way. But leaving them aside, since you've got message instance, is there a reason to not sign everything: received, return path, X-dash, and DKIM and ARC included?

Richard Clayton: There you come into a tracking problem because if you have a system which is DKIM2 at the edges and very simple-minded relays in the middle... right, so you may be moving stuff across your network from one side to the other. You may move it from one email machine to another just by using very simple SMTP. You may wish to put in the received-colon header fields in order to track timestamps and so forth for the transport, but this is not something that you wish to keep track of and keep on signing because it requires you to upgrade the whole of your infrastructure from to DKIM2. The sort of example I have in mind is that years ago we used to have machines which built up big mail queues and we wanted to offload those mail queues onto another system in order to have two people sending out the contents of the mail queue. And the easiest way of doing that was to have machine one relay the message to machine two, right, rather than doing a file copy. We actually sent it over SMTP because all of the software understood that, it got it right, it didn't mangle it, etc. etc. If you're doing that sort of... those sort of tricks, and I'm sure mail admins do that sort of thing from one year to the next even these days, then the fact you'd have to put in DKIM2 signatures just for adding in received header fields seems to us to be over the top. The other thing is that...

Seth Blank: Richard, a quick question. Sure. But presumably, if you've got DKIM on the incoming and DKIM2 on the incoming, DKIM2 on the outgoing, you know what the relays in between are doing. You stick a message instance on the incoming.

Richard Clayton: No you don't. If you're receiver of the email, you don't necessarily know what relayed it to you.

Seth Blank: Okay. Well, Barry, you're up.

Barry Leiba: This is Barry Leiba. I'll start off by saying that I can live with this. But yeah, I agree with Pete in you start saying except this and except that and except the other thing. Now what happens if another exception comes around later? People, since we've been telling them that X-dash is a bad thing, have been putting their private things in without X-dash. Your arguments for why we should exclude X-dash would tell us that we should exclude those as well, but we don't know what they are. It just starts to get to be a bit of a mess. And I think either saying which ones we should sign or we should sign everything with no exceptions. One of those two is better than this "well, yes, but except." So as I said, I can live with this, but I would prefer something a little more definitive. And before you respond to that, I'll just say that on the last thing, I think bottom-up makes sense because new headers are added at the top. So just whatever.

Bron Gondwana: Since Barry did the bottom-up first, this is Bron Gondwana. You're going to have to sort and read in all the headers before you start calculating anyway because you have to alphabetically order them, which takes away the main argument for starting from the top. You're always going to have to load all the headers into memory first. That list there doesn't include message instance and DKIM2-signature, but obviously neither of them are signed because they are the system that all of this happens on, so they're done separately and I'm sure that's covered on a separate slide. I could live with having to explicitly list "received" as being excluded and "return path" as being excluded and possibly having it sign all the X-dash headers as well and say, "As a system, you're just responsible for figuring out what your X-dash headers were." The more things that we have to have in there, the more individual message instance headers we need to add during a mail flow or need to combine together into multiple... like combine multiple of them you've created yourself internally into one on the way out. Certainly the code I've got at the moment adds an X-DKIM2-info which says which software did it, which version of the spec it was using when it did it, so that you can debug what was going on and understand. And that would either have to be added before and merged into the message instance or it would break all the downstream things. So that kind of breakout... but I think if we said that the message instance lists the headers that it doesn't cover, that would give us an escape valve and it would just be received in most cases and maybe return path. And then you can add additional headers there later if there's additional trace headers added without having to change the spec.

Richard Clayton: Repeat please. I would point out that if you add a header and it is signed, then you have to put in a recipe saying what you've added so it can be removed. So if you sign received headers, then you are invariably going to have to put in a recipe which says "I added a received header."

Bron Gondwana: No, my argument is that you just list "I've signed everything except for received," you can add more received without breaking me. So explicitly saying you can add more of something with this specific name without breaking this signature.

Richard Clayton: But bottom line is I don't know why you'd want to sign received because it has no security properties for the actual message which is displayed to you.

Bron Gondwana: No, the point is not hard-coding any specific header names in and just saying that you have to declare which ones you're not signing rather than hard-coding this list. That's the only argument, and it's a future-proofing.

Seth Blank: Lots of vertical head movement in the room. And I think that's a better answer than what's on the screen. Alexey, go ahead. Someone who actually writes a server, you know, those are fun people.

Alexey Melnikov: Yeah, I think plus one to what Bron said. Also, a quick nit in the current suggestion. A lot of MUAs still add X-Mailer, so do we care? In your proposal it'll be excluded but...

Bron Gondwana: You lie about it, who cares?

Seth Blank: Well, and Bron's comment from the floor was "Well, you lie about it so who cares?" I know... one of my reactions as Richard was talking was one of the good reasons to go for as much as possible with exceptions explicitly listed is because you never know what the eventual security properties of any given header field will be. Right? Eventually down the line, people can start using them to discover that, "Oh, well, if it doesn't have this, that was a terrible thing" or "if it does have this, it's a terrible thing." I think being explicit with the received, return path, and, you know, if you have to sign all the X headers or you can say "I'm not going to" and something down the line can decide whether or not that's an important thing to take into account.

Richard Clayton: Yes. I would say by the way that return path is there for completeness. If you follow the rules on return path, then you'd never see it on a message which was still on the wire.

Seth Blank: Theoretically, yeah. Barry, you're in the queue.

Barry Leiba: Yes, this is Barry. So what I would say is that I like Bron's proposal. I don't mind having something non-normative that says "we don't expect these fields to be signed," but that the normative thing is you explicitly say which fields you have not signed.

Seth Blank: So that could go into the BCP/implementation advice document.

Barry Leiba: Well, or in the "how you sign headers" part. I don't mind if it's in this document. I just would prefer that it not be the normative thing, that it just be "these fields are commonly not signed," but still Bron's thing that you have to say which ones you didn't sign.

Seth Blank: Tero.

Tero Kivinen: Received header actually definitely has security properties and it has been used for lots of that, because there's lots of the, you know, spam detection systems who check out where the received headers claim the mail came in and might actually, you know, put the, you know, recognize that this is forwarding device, "Okay, I don't put the bad status for that, I put it the next hop," and so on. So there's... and also another thing which is used very commonly is to see whether the mail was actually encrypted on transit, because usually that header includes, you know, it was using TLS, you know, something and something to protect it. So you can actually use it as a forensic tool later to see that whether the mail was actually sent in clear anywhere or something like that. So... but unfortunately, I don't think we actually can sign it anywhere but it's... it's funny to say that it doesn't have a security property. It does.

Seth Blank: And I think, yes, what Tero's saying goes with how I reacted, which is I think trying to imagine what all the security properties are is a red herring. There's a reason pragmatically, I think, that Richard's described well, that received headers are going to be a pain to sign because you're going to have to have message instance all over the place and you're going to have to keep track of things. So the explicit move says for pragmatic reasons I didn't sign this, and whoever is down the line can decide what they want to do about the fact that unsigned changes came through with the message. Bron.

Bron Gondwana: Yeah, certainly if we allowed a syntax that let you say X-dash-star as well to say anything that starts with X is excluded, then you could describe basically what's right there in a line. Each message instance would be that much longer saying these are what we're excluding. And then we could change that later without needing to rev the spec.

Seth Blank: And Richard, you get to close out the queue and then continue on with your presentation.

Richard Clayton: Okay. I was basically going to say that... received... if you trust received headers apart from the one you put on yourself, then you are in a very poor place and you shouldn't do that. And your own one is not going to be signed because it was put on as the message arrived and you're not necessarily DKIM signing at that point. So, you need to think about these things really, really, really carefully. But okay, we've covered this and we'll see where we go wherever. If people are happy with bottom-up, we can do bottom-up so it's just like recipes. It's no big deal. Okay. My next slide is our current thinking on recipes.

Now, we put recipes into a JSON structure because it was going to be easier to parse them. Because if you have a JSON structure in these headers, as Tobias originally pointed out to us, then it's really easy because what you can do is you take your base64 string and you throw it at the base64 decoder library, and then you take the resulting thing and you throw it at your JSON library, and your JSON library will give you an in-store data structure which you can then walk and so forth. You don't have to fluff around with parsing and so forth. If you want to write your JSON decoder yourself, that's just fine. People seem to be getting excited on the list about "there is no normative way of ordering JSON" and etc. etc. We doesn't need to be because you can produce anything which is valid JSON, encode it, and then a JSON decoder will decode it into the correct data structure. The rest of it doesn't really matter very much.

What I will say is that I have written four JSON schemas in my life and it turns out they're all wrong. We're getting rid of two of them. This one is we think should remain because it basically saves you writing quite a lot of custom parsing for parsing the recipes. In the 08, I rather foolishly put the numbers into strings. They didn't ought to be strings, they should be just integers so you can just pick them out directly rather than decoding the strings. And the other thing to point out is that since JSON has UTF-8 strings out of the box, then if you need to express the fact that you have done something to a body or to a header field which involves UTF-8, then you can just do that in the JSON. It's not a problem. And it will just handle it correctly. And there's not a problem the fact that there's some UTF floating around, exotic characters, because it's going to be base64 encoded before it's put in the tag-value field, at which point the tag-value field parsing is very straightforward. Okay. So, once again, we have the question of whether or not we're going to number the header fields from the bottom, which makes the ranges more logical, or from the top, which for some purposes may be easier to code. Bron is real keen that we number them from the bottom. If people are happy... I think there is an argument for numbering them the same way for both the concatenation which we've just been talking about, for the hashes and for the recipes. Doing them differently for each is just asking for people to get it wrong. That's what I have on that.

Seth Blank: So, a comment in the room. Alexey's for "from the bottom" for consistency's sake. And a couple of plus-ones on that. Bron?

Bron Gondwana: Yeah, the specific thing that came up on the list here about the recipe shape itself was that if the recipes have a set of strings and arrays inside an array, a lot of JSON parsers get very unhappy about that, that there's different data types in a single array. And so we may need to change the format for that so that it's individual hashes with items within it. I can write up some text on that. I think something that might make a lot of sense as a regular thing is you either have a copy which is a list of lines or an add text which is a list of lines. So you could have a single statement which is "add this array of lines" rather than one statement per. But I'll write the text up for that.

Richard Clayton: Writing the schema would be even more helpful.

Bron Gondwana: I'll write up the schema for that. Thank you.

Seth Blank: Any other comments on the recipe JSON structures? I'm happy that there's less than controversy about that. Good.

Richard Clayton: Well, to be fair, Pete, there has been some controversy on the list that there are some people who seem to think that putting in some JSON is the end of the world and so forth and their milters cannot cope. It escapes me why this might be because you can write milters in pretty much any language you wish, and therefore you ought to be able to cope with JSON in any language you wish. I think what they mean is "my existing milter has never heard of JSON and therefore I'm going to have to have a new milter." And that I will agree with, and but I think you possibly need a new milter for dealing with DKIM2 because it's not quite the same as DKIM1.

Seth Blank: Right. All right. Next slide.

Richard Clayton: Okay. Right. Just to remind everybody, the DKIM2-signature header field is also a tag-value field. It has rather more values in it. It has an I equals which just numbers the DKIM2 signatures, start at one, go up simply ascending thereafter. Each DKIM2 signature field contains a V equals which indicates what the highest message instance is at the point at which this signature was created. Has a nonce value which is there for anything which you want to make it there for. It is just a number. You might find it useful to put a database reference in there or something like that so that when you got a bounce or something you could do some lookups or whatever. Or you could just put 42 in there because you thought that was a good idea. It's completely up to you. There's a timestamp. We haven't said very much recently about timestamps but DKIM2 has timestamps in signatures so you can know if emails are really old and were signed a very long time ago because you might not like to receive them because you thought there was some sort of replay. There is then a JSON structure which again is a JSON structure and is turned into base64 which contains the RFC 5321 parameters, mail from and receipt to. Next slide on that. There's some flags and there are four flags. We have rather departed from the DKIM1 scheme of using single letters for flags and we spelled them out in full. We could go back to writing D, E, F, G or whatever if we could think of some things for that if people thought that was a better way of doing it, but anyway we have flags. We then have the signing domain, and then we have the selector, the algorithm, and a signature. We reuse DKIM1 signatures and keys and selectors and so forth. This is great because it means people who are hiring ESPs to send their mail don't have to do anything whatsoever to their email DNS setup. They just keep on using... they're just putting keys just as before and the ESP does all the hard work of dealing with the fact they're in a DKIM2 world and the very, very large number of brands and domain owners and so forth don't have to do anything at all. So this is a key design decision.

Anyway, our current thinking on the signature field. Now, if you look at 08, you'll see that there is a very badly defined JSON structure because I'm not any good at JSON structures—did I say that before? And there is no need for it to be in JSON. Thank you very much, John. So what we're currently proposing is just to have S equals, then the selector, the algorithm, and the signature value, and then repeat those triples if you have more than one algorithm in use. This seems like a no-brainer to go to this scheme, and in particular it fixes a technical issue with what was being proposed before, which basically meant that when you actually create a signature field, obviously there isn't a signature there for you to sign, so there has to be sort of nothing. And specifying how you put nothing into a JSON structure in order to sign and make sure you sign the selector and the algorithm, because you'd like to sign those two, was really hard to explain. If we go to this, then you can just put in the signature. Now, having thought about it today, I'm a little concerned about putting "nothing" for the signature because of the way in which you can scatter around white space in and around base64 strings and in and around syntax in tag-value fields traditionally because people want to make them wrap nicely and not hit the thousand character limit. So as a result of that, I'm actually... I've actually written the 09 which nobody has seen yet apart from I slipped a copy to Bron earlier. The 09 basically says that instead of putting nothing there, we'll put a dot, because that means that you can get the white space correct and so forth.

Now, it will be noted in that we have written down the selector, the algorithm, and the signature, and we do not publish the hash. This is intentional because what this means is that if you have a post-quantum or any signature scheme—post-quantum springs to mind, but the elliptic curve as well—and it has its own hash built into it, right, then we don't necessarily have to do a hash and then sign the hash. You can just produce a signature, right? So we could actually use ED25 or whatever it is, the elliptic curve thing, but we could use that without using the SHA-256 hash, which is what is currently defined. We could let it do its own hash as part of doing the signing because we don't need to publish the hash and we haven't put it there. So that is why that looks as it is. And Steven, I note in the notes because I know he knows more about post-quantum than all of us here put together, will probably say this is a good idea. I also concerned about how long the hashes might be in post-quantum, so there we go.

Bron Gondwana: I've been answering in the chat as well that the question of customers of ESPs not needing to do anything. The answer to that is if the existing DNS records work for DKIM2 without any changes required, then the ESP updates their software, the messages go out DKIM2 signed instead of DKIM signed or both, and the customer, the owner of the brand domain that is being signed on behalf, doesn't have to make any changes themselves. That's the argument, not that the ESPs themselves don't have to change their software. Regarding this, I also had some thoughts this morning, Richard, that nothing in message instance or DKIM2 signature has any significant white space whatsoever. So we could define a different algorithm that strips everything when we're normalizing it, strips all white space rather than folds white space to a single white space. And that would mean that the signing is much more reliable across whatever folding you feel like doing and you can refold those headers later with no damage done.

Richard Clayton: Okay, it would mean you couldn't use the same folding code as we use on the standard... the rest of the header fields.

Bron Gondwana: Yeah, that's correct. That might not be a big deal.

Richard Clayton: Yeah. All right. The other thing is we could just not put in some of the FWSs which are scattered around next to every syntax item to help with wrapping because you're allowed to put... in DKIM, you're allowed to put spaces into the middle of base64 strings anyway you wish.

Seth Blank: Yep. Any other comments on the signature field? Questions? Happy thoughts for the day? All right. Next slide, Richard.

Richard Clayton: Ah, there's a certain amount of lag here. Okay. Right. What the spec currently says is that you should sign all of the message instance header fields in numerical order, ascending, then all of the DKIM2 signature fields in ascending order, and then finally the last thing you throw into your signature algorithm is an incomplete version of the header field which you're in the process of making. Bron suggested on the list that maybe one should, instead of doing it all message instance, all DKIM2, one should put them in in some sort of creation order, as they had been added to the message, and that you might be able to use some of that in order to help you with your validation because when you do validation, you were going to check only some of the fields, not all of them. It's kind of tidy to do that, but I and Hannah, who also I think commented on this, think this to be really rather a mess to actually implement, because you can no longer just throw all of your headers into a hash of arrays, a dictionary of arrays if you're a Python person, and then just iterate through it. You have to hop backwards and forwards between two data structures, and that seems rather complicated. But it's not impossible to do. And as just commented, I made a mess of it before. I made a mess of it before in terms of signing the selector and the algorithm. The change to the S field fixes that. But yes, the...

Just to remind everybody, the whole point here is that in DKIM2, the signature is only applied to the message instance and DKIM2 signature header fields, nothing else. Because the message instances contain all the hashes for the body and all the other headers and therefore you're effectively signing those, but you don't have to go and collect them all over again. And that's...

Seth Blank: Any comments? Questions? Bron is happy with the changes. No concerns. I'm so far liking it, very smoothly going. All right, moving on.

Richard Clayton: Okay. Right. Now, in the current draft, we say that the mail from and receipt to values, which we believe we need to record in order to address the DKIM replay issues, that they are put into a JSON structure. The JSON structure, as I keep on saying, I made a mess of specifying it, but it is very elegant and the way in which we deal with multiple receipt tos is basically hidden away from everything. Now, the reason that we put it into a JSON structure in the first place is because mail from and receipt to contain local parts of email addresses. And local parts of email addresses can contain a wide range of ASCII characters between the values of hex 20 and hex 30, for which we will blame Dave Crocker because it was probably all his fault that he did this. Oh, I see John Postel for the first go round. Right, okay. We have regretted it ever since because all sorts of people put all sorts of funny characters in there and naive parsers screw up.

Anyway, because they can contain things like semicolons and so forth into local parts—not that anybody does, but you can in theory—that means that if you put the mail from and receipt to directly into the tag-value thing, then either you need to encode things or provide escapes or something, or you need a 5321 parser in order to walk down the tag-value field. And since we believe most people are going to take the tag-value fields and say "split on the semicolons," "split on the equals," "split on the commas," and "split on the colons" and things like that, they are going to be sorely disappointed one day when somebody finally sends a message through with one of these semicolons sitting in a local part and they will be very, very sad and everyone will point and laugh at them. So that is why we put it into JSON, because that is a rigorously correct way. We can write the ABNF and it's all just fine.

Now some people don't like this. Way has commented a number of times on the list and may well, if he's on the call, he can put his own point of view directly. They say this is very disappointing because that means that these things are not human-readable. And that is basically correct. However, as I was pointing out on the list, these days you don't need to write a program in order to be able to translate base64 for you and you don't need to go and find a webpage containing a base64 decoder. You can just say to your local AI, which is built into your browser, "Translate this for me," and it will kind of do it. The only thing is that if you say "Translate this base64," I understand sometimes it will reply, rather like if you ask it a question in German, it will reply in German. If you ask it a question in base64, it may actually reply in base64. So be a little bit explicit about what you want it to do. So yes, it is sad it is not human-readable, but I don't have a good fix for it. The most elegant fix for it, if you don't want to do escapes and stuff like that and you don't want 5321 parsers, is that you put all of these fields into a completely separate header field, and then you can fix the parsing so you can parse that just fine. That seems like more work and we have three headers to keep track of and line up and so forth. So we'd rather put it in the JSON. And as ever, if you put it in the JSON, then calling your standard libraries means you'll get a nice in-store data structure and you can do all of the stuff you want to do.

Seth Blank: Well, both of your co-authors including Wei are in the queue. So Bron, you want to give your go first?

Bron Gondwana: Yeah, I'm putting my very strong argument for using the JSON. And the reason for it is that a lot of bugs that we've found in a lot of software has been being clever about syntax and being clever about the ways that we encode and decode things. And the more layers of encoding and decoding you have, specifically optional ones, the things work most of the time until you hit a weird edge case. That's the spot where stuff breaks badly. So having something that is used all the time, which the JSON is, you don't have any choice but to implement JSON, and JSON itself has the structure built in, so you get structured data rather than data that you have to decode with a mostly correct guess, I think is... makes a much more robust spec. And yes, I am sad that I can't read it. But hey, that's privacy as well, right? If you have to paste it into your browser, which then sends it to the central data collection machine and knows who you've been getting emails from.

Seth Blank: Privacy via base64. Wei, tell your co-authors why they are so sadly mistaken.

Wei Chuang: I don't think they're mistaken. I think it's just a difference of opinion. So I think there's an important value in keeping some of these things very plain. So my worry, and I put it out there in the mailing list, is that we need to often see these different domains for the purposes of seeing alignment so that we can go debug problems. That invariably will happen. I also put out some thoughts—not fully formed then, probably still not fully formed now—but that, you know, we can use some of these other headers to basically provide the equivalent, or some of the equivalent, of the mail from and receipt to. You know, for example, one way of doing this might be, "well let's just take, you know, some of the existing headers to, you know, we... uh... you... uh... can... put... uh... like... the destination headers basically and then basically, you know, To, CC, and BCC, and use them. And often times the repeats are going to be with those addresses, right? And then, you know, that of course can parse naturally." The if we do and, you know, for subsequent forwarded message, we often see that they're going to be singletons anyway. If we need to create a brand new header for this, I don't think that would be that much trouble. And then we can solve a lot of those problems that way. And I think we can solve a good deal of the complexity of I think the DKIM2 signature by simplifying and making, you know, removing the JSON base64 for just that special case. So that's basically my argument, that you know, we need to be able to see these values for debuggability.

Seth Blank: Bron, you're up. Although I would love to also see some of the non-authors of this document get into the queue and give their opinion.

Bron Gondwana: I'd be interested in seeing Wei how an example of how that looks with some various cases because to me it feels much more fragile and likely to be got wrong. Yes, it's harder for a human unaided to read the headers, but you could easily write a tool that does the debugging and takes the either copy-paste the headers or just reads the message directly from where it's stored. And generally that's what you'd be doing anyway if you're also doing checks that signatures pass, etc. And so you could have your tool that does the signature pass checks also spit out what it found in those fields. Which is what my tool does. And then you avoid that problem entirely, assuming you trust your tool.

Seth Blank: Am I to read the lack of input from others as "we don't really care as much as the authors do?" Barry's shaking his head up and down. Ken, go ahead.

Ken Murchison: Non-author. Plus one to using JSON. As Bron said, trying to do escaping of semicolons and commas and all that other garbage is fraught with errors. Just look at how bad V-card is in terms of escaping. So let's not try to duplicate that here.

Seth Blank: Okay, my entreaty went well. Arnt, you're up.

Arnt Gulbrandsen: Non-author. Arnt. And I think that good and progress beats best. Recent history strengthens my belief, so terribly happy that Richard and others are doing good work and let's not quibble too much about details.

Seth Blank: Okay, good. Alan.

Alan: I know in the interim I expressed that I wasn't super happy with the JSON thing. I haven't had as much time to think about it since then as I'd like, but I have not come up with anything better. So I would begrudgingly support continuing along this JSON path.

Seth Blank: Fair. John Levine.

John Levine: Hi there. Just to pile on. Having witnessed some of these buggy parser things that attempt to deal with all the special characters that are partly Pete's fault... I would be delighted to use someone else's JSON library. And as I said semi-seriously in the chat, you know, like if you want to be able to trace these things, you could add an X-DKIM2-decoded-envelope-bits header, which is a comment, you know, to tell people "well here's what's inside the JSON," you know? It might be a lie, but if it was just for debugging, why not?

Seth Blank: I think that's an interesting attempt. All right. So what I'm hearing in the room today is that one of the three co-authors may be sliding into the rough part of the rough consensus, but we'll, you know, I'll do the write-up of the minutes and get this on the list and certainly Wei can make his case to the rest of the list and we'll see where we go. Although I mean as tongue-in-cheek as John Levine's comment was about just burst it out into a comment if you like, that may be sufficient. Barry.

Barry Leiba: I'm sorry, I didn't click the button, but I would propose that you post to the list as "If you can't live with JSON, tell us why."

Seth Blank: Yes, absolutely. Barry and I share a style of asking the questions. All right. I think we have sufficiently beaten that horse. Next slide, Richard.

Richard Clayton: Okay. Right. This is something that came up pretty recently, which is that in DKIM1, there is a description of the verification algorithm. And it kind of says, "You should have a verification algorithm and it should produce the three results: This was just okay, this is wrong and it will never be right, or a temporary fail, which means, well, I had to go and look at some DNS and that didn't really work out and it timed out and so forth, so it might work if you try again later." When the DKIM1 results were put into the authentication results RFC—8601 is the latest in a long line of those—then it ended up acquiring multiple states. Apparently because people wanted to have just as many states for DKIM as they have for SPF. So you have none, pass, fail, policy, neutral, temperror, and permerror. And I refer you to the fine documentation for understanding what they all mean.

The suggestion which has been made is that it might be a good idea for us to align the DKIM2 with 8601 and to set out not the sort of the description of the protocol in terms of what a verifier should do in terms of it should produce none, pass, fail, policy, neutral, etc., temperror, and permerror, and explain what those were in a DKIM2 context as part one. And secondly, that we should write the documentation in such a way as to encourage systems to use some consistent text strings to describe these particular events which go wrong. Because what has actually happened with DKIM1 is that the people who wrote the libraries, which everyone uses for DKIM1, copied various strings out of the text which was written in the RFC, and those text strings come out of the libraries, and those text strings get copied then into the SMTP protocol, into the 5XX or 4XX returns as a comment in those strings. So the first bit, you know, sort of says 521 and then there's an extended error code and then it has an explanatory piece of text, and that explanatory piece of text came from the RFC. And the thought was expressed when we were talking about whether or not we should make this stuff line up, that maybe we should be strongly encouraging people to generate a consistent set of strings which we put into the document, and those consistent set of strings people should be strongly encouraged to put into 5XX and 4XX strings because that way people would understand more better why their email was failing to authenticate and so forth. And it's not really debugging in the sense of it's troubleshooting when things go wrong, which we do all the time way beyond the point at which everyone thinks the code works, we're still trying to make systems work. And generally I think that's a good idea. The extent to which this is put into the specification document and the extent to which it goes into Todd Herr's document, I think is unclear at the current point of time, but I wanted to put it on the slide and have the room discuss this to see whether or not this was a good direction to go in or whether or not it was not the purpose of a protocol spec to tell people what error messages to produce.

Barry Leiba: This is Barry. Sorry, you used a lot of words there and I think you started talking me into and out of things at the same time, so I suggest that you tursify a bit. But I am all for having consistent strings and using them in multiple places. The main thing I want to see here is that what comes out of the signature verification is a set of things that the signature verification actually tells us and not trying to add more nuances than are actually produced by verifying a signature. So we should really think about this and decide "are these two things really distinct outputs from a signature verification or are they just nuances we're trying to add that don't reflect the technical thing we've just accomplished?"

Wei Chuang: So I think there's two parts here. And I think the first part is trying to modernize and trying to put into the specification the results that would then get propagated onwards to potentially some other receiver that could be useful for debugging and communicating results. I think, you know, 8601 is sort of the standard for the way how we do that. And I think by putting some details into, you know, what all... it doesn't have to be all of the these different values, it's probably just three that represent, you know, what the above thing—okay, permerror, temperror, that sort of thing is—but having that in the specification is very useful because then we can all agree upon what they mean. Now, for the second part, that's kind of more for I think this interoperability experiment and the bring-up. And I think that doesn't have to be quite as permanent, but if it is, that's also probably fine too. I was thinking maybe this could be a thing that could be put into the appendix or the BCP, doesn't matter, but basically a common set of language to communicate to people trying to do that bring up that interoperability on some common results that could help communicate, "hey, you've got a failure here and it's because of this particular, you know... there may be, you know, multiple hashes failing, right? Which one? That type of thing to help describe what went wrong." And that way we can try to debug during the interop. The other thing I just wanted to point out there is that there's also an comment field in the authentication results that this string could go into. And I think, you know, there's sometimes, you know, the results may also be useful to propagate there. And that's my point.

Seth Blank: Thanks, Wei. I put myself in the queue just to repeat what I put in the chat, which is, you know, extended error codes are pretty darn close to infinite. We can define loads of them and loads of sub-codes to give good, you know, fine-grained advice about what happened. I'm not convinced that requiring particular text strings is a good idea, but certainly examples of what that extended error code means and people reusing them seems like a fine outcome. So I would stick with the idea of, you know, do the 5 or 4XX, do an extended error code to give fine-grained detail, and then give text for what those extended error codes mean.

Wei Chuang: Just to pile on there. I mean, my thinking there was basically these is hopefully things that will come out of the interop. And I mean, again, it doesn't have to make it into the final specification, but it's there to assist people during interop to communicate a common result and have that available, you know, whatever the most convenient document may be, the BCP or like maybe an appendix. And right, I agree there is a risk that we can try to over-specify ad nauseam all of the different failure modes. I think the people that ought to be specifying are the people that are on the ground that are actually trying to do that interop experiment and then, you know, whatever they find, we can just document what it is and then we can just have like almost like a living document that that describes these things in some place.

Seth Blank: Okay. Anything else on result values? Last slide, Richard.

Richard Clayton: Okay. Technically this is Wei's, except that Wei produced this because I was too lazy and I said, "Please, Wei, could you write this draft because I don't want to? But here's what it should say."

Seth Blank: Wei, do you want to present it or...

Wei Chuang: I'm either way's fine. I... go ahead, Richard, if you want or I can go.

Richard Clayton: I'll... I'll go through it quickly and then you can chip in with the... what it actually said. Basically, there are a number of exotic fields which you could put into the DNS to accompany your DKIM1 key. Your DKIM key because they're the same between one and two. And those and the exotic things you can put in are in particular you can put in an H equals field which says "I suggest you use this hash with this key," which is a bit late, particularly in DKIM2 because we've already done the hashing, so that's a bit odd. Secondly, there's an S equals which says "This key is only meant to be used for the following purposes." And if it doesn't say "S equals," if it's not absent or says "S equals email," then you should... then despite the fact that somebody has used this in order to sign something, you should not use it for email because there's a statement in the DNS that says this is not meant to be used for email. Now this I think comes from an era where people thought that the DKIM keys and so forth would be terribly useful for all sorts of other things as well, but in practice nobody is using DKIM keys for anything other than for DKIM. So and the other exotic field which you can find in there is an N equals which is basically a comment and the RFC says something about this might be useful for administrators who have forgotten why they put the key into the DNS in the first place and it will remind them not to take it out again, or something like that. So basically, none of these seem a particularly useful thing to discover and they mean that when you go and fetch the key you suddenly discover you can't use it, or you're being told not to use this hash with it or something and so basically almost nobody has ever read the that bit of the spec, so almost nobody is actually putting any of these fields in there. We've been doing a little bit of work trying to find if anybody has and turning up almost nothing. So we thought we'd just deprecate them and tell people don't set these and by the way if you do set them DKIM2 is going to take no notice anyway.

The other thing which is in there but is optional is that you can write a K equals which says which signing algorithm this key is meant to be used for. So you can put a K equals RSA or you can put a K equals Ed25519—never remember the number—25519. So you can put that in, and potentially that it's kind of odd because if you went off to fetch this key because somebody said "use this RSA signing key" and then you turned up on that selector and it said "Ed25519 instead," well, you know, you've done all this work to get the key and then it's saying it's the wrong one. So this doesn't seem a particularly useful thing to put, but it does stop you shooting yourself in the foot perhaps so maybe K equals is useful. Finally there's some flag fields. Do with the second one first, T equals S is a thing that says your... this key must be used with an agent which lines up with the domain which is doing the signing, but we got rid of agents in DKIM2 and nobody has ever noticed the fact that we did that.It's really hard to tell if something is missing, so nobody's noticed we got rid of agents. So we don't need the T=S field, it doesn't do anything. And then there's a thing that says T=Y which says "I am testing." And what that means is in the eye of the beholder because... etc., etc. So the people who fetch this and discover it says testing might do something different, but nobody's quite clear why. And the reason it says it's sad for Google is because Google made a decision a while ago that if the key was being used for testing then it wasn't meant for production and therefore it didn't count as a signature at all and therefore they count that as not being signed. Which is a great disappointment for the large number of people who have set T=Y because at one point that was felt to be the right thing to do because people were moving from DomainKeys to DKIM and setting this flag was sort of in various popular blogs about how to do it and you were recommended to set this. And it turns out there's quite a lot of domains which are setting this and they are having a disappointing time with Google which they probably don't realize. So basically most of the flags in there aren't very useful in the real world and so the notion is that the draft which we're hoping the working group will adopt fairly soon will say "If you put these fields in, then a RFC-compliant DKIM1 implementation may take some notice of them, so be careful. But if you're using DKIM2, using this key with DKIM2, then these fields are completely useless and will all be treated as comments." And Way has expressed this in some language which we may or may not feel is consistent with what I just said.

Seth Blank: Jim, you are first in the queue.

Jim Fenton: Hi there. So I think I was probably one of the early proponents of S= because I thought that this whole business of having public keys in the DNS was useful for a number of things that were kind of, you know, maybe orthogonal. I actually do have a very small service that uses S= for something else, but I don't think it's going to go anywhere. And there is probably not a huge amount of danger if somebody were to perhaps try to interpret... I mean there's not much likelihood that somebody's going to get an email message signed with that key anyway. So as long as I can have the selector there for something else, this is fine.

Seth Blank: Good enough. Alan.

Alan: So on the T=Y piece, how do we deal with the existing deployed base if all of a sudden their key has a meaning that's different than what it has today?

Richard Clayton: That's their problem for putting it in... for using it and putting it into the selector. At the moment, if it says T=Y and you send email to anybody other than Google, we believe that everybody thinks that's DKIM-signed. And if you send it to Google, Google says it's not DKIM-signed. So what will happen is if they use it for DKIM2, they'll suddenly discover it's signed after all.

Alan: Okay. I don't know why we're asserting that every DKIM verifier except for Google has decided to ignore 6376, which says explicitly that these are not supposed to be treated as signed. But yeah, I mean I think it's highly theoretical that you'd have a DKIM2 signature that comes out with using a key that has those.

Seth Blank: I mean, are there a lot of T=Y keys out there?

Richard Clayton: Yes. There's a whole lot of stuff sitting at Salesforce, because Al Iverson actually did a scan. We'll try and post his results to the working group list. We've not scanned the entire internet yet, but there's a whole lot of stuff at Salesforce, and this appears to be a... they thought it was for some time they thought it was the right thing to do, so they did it.

Seth Blank: Someone should talk with Dave Lawrence. And Barry says someone should talk with Dave Lawrence. Yeah. I think we need to do a little more research into what's actually happening out there, or at least for those of you who have looked into this, maybe publish what you've found or as much as what you've found to the list. That would be interesting.

Richard Clayton: Well, what I would say is philosophically I think my personal opinion is that if you want to do testing, you should not do it on the open internet with strangers. You should do it with your friends and use a different selector and test with that. And when you're happy it works, then put... then start using it in production. The idea that you put something into production and then say "ignore this" is just... it's operationally not a good idea.

Seth Blank: Agreed. Not a good idea. I'm not seeing a whole lot of other jumping up for other flags. All right, we will go from there. And that I believe is all you've got, Richard, yes?

Richard Clayton: Yes, I thought that was quite a lot really.

Seth Blank: Yes. Okay. We have 25 minutes left. So, let me switch slides here. Do I have to take away... take back control? I'd love how that works. All right. Get... Okay. So I will get minutes written up as quickly as possible after the meeting with proposed consensus thoughts and requests for people to object to my thoughts on that.

Next item on the list: interims. So Murray and I talked, we still think this is a good idea to make regular progress. Barry gives a thumbs up in the room. We are thinking that monthly would be a good idea. When we did the discussion of times, the time of day which I believe was Wednesday, I believe late night UTC, someone can remind me...

Bron Gondwana: 1:00 p.m. Eastern.

Seth Blank: 1:00 p.m. Pacific, sorry, apologies. 1:00 p.m. Pacific, three... right, 4:00 p.m. Eastern, and that'd make it 9:00 p.m. UTC. Something like that. Anyway, that seemed to be least horrible for most people. So we were thinking of doing that as a monthly gig and put them up on the IETF calendar. A thumbs up from Bron, assorted nodding heads. Any objections to doing this? Anybody think that monthly is too infrequent, too frequent? No one seems to have much complaint or comment. Okay. We will go with that and we'll see how it turns out. Alan says no more than monthly. Fair. I think that's probably exactly right. Okay. So we will go ahead and get those scheduled, which leaves us with any other business. Anybody have anything? Folks in the room, please get in the queue if you want. I am happy to give back 20-odd minutes. Go get a snack before the snacks are out. Yeah, it's lunchtime, or we have one more session and then lunchtime. Just a beverage break. Going once... Bron?

Bron Gondwana: I was just going to say, Richard, I'll send you a pull request with the changes we've suggested.

Seth Blank: Excellent. Going once, going twice... Thank you all. That was a very useful meeting, and I think we've made good progress. Thank you all for staying up late, those who did. Alrighty. Cheers from the chat.

The next food we get served is 4:00 p.m., the farewell reception. Is this the end of them? This is mine and I'm heading to the registration and... When do you leave? Saturday. What time? 12:30. Friday at 5:30. I am taking the early train. It is the fastest way, so I'll find out. What? I took the earliest train. Yeah, just because I'd rather hang out at the airport lounge than in the hotel or... exactly. I care not. Okay, I'll go ahead and shut off. Save batteries. I think the current... okay. That's interesting. I thought I turned it off. Lower switch. Yes. It does not appear to be functioning. Let me look at the other... you should turn up. Oh, straight down. Got it. Yeah, perfect. Thank you.