Minutes from the IETF 123 DKIM WG

Madrid, Spain
2025-07-22 15:00 CET

Administrivia

Meeting called to order. The chairs presented the Note Well and other process and conduct reminders. The agenda was presented and bashed, with no proposed changes.

Discussion of Header Draft(s)

A poll was run; about 50% of participants have read the candidate documents. The chairs expressed concern at the low number.

Discussion:

• Richard Clayton: Noted that the Crocker and Nurpmeso drafts are slowly converging toward Bron’s draft. We should adopt Bron’s draft; it has all the things we need. Approaches that seek to extend existing DKIM signature header fields fall short of dealing with some issues that have arisen with contemporary use of that specification, including oversigning, backscatter/feedback.
• Dave Crocker: Assembled a table of the functional goals we’re trying to solve based on the motivations draft and the charter. Advocates the benefits of a divide-and-conquer approach to addressing these; allows for compatibilities the current work does not have. The convergence referenced by Richard demonstrates the value of the dialog we’ve been having. The DKOR draft addresses one specific function in a way that’s compatible with the installed base, which is beneficial and this needs more appreciation. This is a core need that has not been getting due attention even though it’s called out in the charter. It is premature to pursue the proposed header specification as it is too soon to adopt all of that at once. Aggressively encourages people to comment on and discuss what’s in the table.
• Allen Robinson: Read the three docs over the weekend. We’re all moving in a very similar direction, which is promising; nothing unreasonable is going on. Have a slight preference toward Bron’s document as it aligns with his expectations of approach, though all three documents have things I’d like to see in a solution. Bron’s document has diff support, which is critical; any solution without that falls apart. DKOR, for instance, does not address this.
• Pete Resnick: Does the diff stuff need to be folded into one of the other drafts before we could adopt them, or should we adopt two of the others? Something else?
• Allen Robinson: Folding in diff support might be better. Don’t know that it’s needed for adoptability. Adopting one that doesn’t have diffs might be a good starting point as long as it’s folded in later.
• Wei Chuang: Similar to Allen’s position. Glad there’s a gradual convergence. We also need the notion of a forwarder instance number, and a reversal algebra. Folks are gradually adopting all of these. Bron’s document has a lot more of the things we need. I would like to push back on the notion of compatibility with the current form of DKIM; there is an established base, but it also has a specific way of interpreting results and there’s a large risk of disrupting deliverability. It’s better to interpret all of the new work separately. We can adopt the tag/value syntax for DNS material and a new header field. I had a hard time understanding the Nurpmeso document.
• Bron Gondwana: I wouldn’t say my draft is complete, and splitting it apart is fine. We should discuss that. It’s important that we have a complete thing so that we can reliably identify a message from a bad actor. I want to be careful that the whole solution has the best results versus a piecemeal solution which has no such guarantee and heuristics will be needed. Ensuring that this hole is closed is key. DKOR has a lot of good stuff, I would be happy to work from that as well. The Nurpmeso document doesn’t seem to be as complete, e.g., its diff structure can’t describe removed material. There’s more experimentation to be done. A diff capability is key; we need to know who made what change, i.e., check any previous host’s work. Also need to establish obligations on forwarders to deal with bounces.
• Murray Kucherawy: Dave’s table breaks things down into ten issues. Imagine each gets its own draft. This would allow us to update each sub-solution easily in the future, especially if they’re purely incremental.
• Dave Crocker: In the early days of programming, there was an attempt at discipline. Prior to that, spaghetti code was common rather than structured programming which is preferred. The danger here is a spaghetti code sort of design approach. There was also the debate of top-down vs. bottom-up. The structured programming approach prevailed, which led to “inside-out” design. That’s where we should start in order to get clarity about the pieces. This discussion shows the challenge, i.e., a confusion about what are the component pieces versus what is the final goal. DKOR is not meant to exclude needed capabilities while also being compatible with the installed base, while Bron’s document tosses that away. I don’t agree with the latter. We should have the incremental discussion.
• Bron Gondwana: The header field draft changes the name of the header field specifically to ensure that a legacy DKIM verifier won’t return a false negative or positive should we start adding new semantics with the same header field name. A “bad actor” is one that lies having received the message organically or is behaving improperly; we should enumerate these cases, and I’m open to talking about a better definition.
• Pete Resnick: Maybe you and Dave should have some direct mic time. Go!
• Dave Crocker: Earlier you jumped to the end of the set of required features, which shows the challenge of separating the steps from the endpoint. DKOR not including a diff capability at this early stage doesn’t make sense, but needing them to be in the same spec doesn’t make sense to me. Can you clarify?
• Bron Gondwana: They need to be together because without both at the same time, you can’t get the properties that I believe are necessary, i.e., the ability to verify the work of previous hops. This is necessary to not create a hole through which spam can sneak via actions of a bad actor.
• Dave Crocker: But you’re describing integration of the components rather than defining them.
• Bron Gondwana: I don’t believe it’s worth defining individual components without also defining their convergence.
• Dave Crocker: I think you said you can’t define the components unless you define them together because without observing their working together, the goal is lost.
• Bron Gondwana: The goal is to interoperate with existing verifiers without provoking false negatives or positives. If we make increments on DKIM by extending it, that becomes a risk.
• Dave Crocker: I think I’m hearing that doing one component without the other will lead to a worse outcome than doing them together, but that misses whether it permits a better outcome than what we have now.
• Bron Gondwana: I don’t think it’s worth the work of the partial better outcome, as the solution isn’t complete.
• Dave Crocker: The language you’re using is worried about failure conditions.
• Bron Gondwana: I’m concerned about false negatives and positives.
• Richard Clayton: I want to push back on the notion that Bron’s draft breaks everything. It’s a result of long discussions among Yahoo!, Fastmail, and Google after dealing with large volumes of mail and DKIM signatures, observing problems in the real world with DKIM. We have quite a lot of experience, yielding a draft describing a fully formed solution. We have considered the tradeoffs among various solutions. We shouldn’t apologize for that or accept the idea that it’s “too complete”.
• Pete Resnick, interjecting: I don’t think it matters that it came out of a long discussion or that it came out of particular participants. The question on the table is simply what we should adopt here. With the exception of the Nurpmeso draft, which people are having trouble with, it’s about how we go forward with the work before us, i.e., what’s a good starting point. I want to hear what the technical process to follow is.
• Richard Clayton: With regard to splitting things up, we’ve split out things like the change algebra as we felt that was a major piece that’s still unclear. We also split out keys as we’ve re-used the older DKIM keys. Users of the new scheme won’t have to do anything other than update software, which happens all the time, so we didn’t see this as a big deal. So we split out topics that were reasonably separable, and in the remaining document we discussed them as a whole.
• Bron Gondwana: Responding to chat mainly: Upgrading software doesn’t happen fast, but systems with very large scale all deciding to do things at once can cause the whole industry to upgrade. This is how https rolled out: Browsers in unison decided it was now a requirement. We know this will take years. It needs to be complete enough to give operators time to close any holes this reveals.
• Jim Fenton: On compatibility, we seem to be getting focused on a particular case of lists that break legacy DKIM signatures but will pass a DKIM2 signature, but we’re ignoring the case of legacy signatures passing. Meanwhile, even with DKIM2 rolling out, DKIM will still tell you something about operators that haven’t updated. I’m having bad flashbacks to Karnaugh maps from logic design class. It would be bad to get into a situation where there’s a lot of DKIM and a lot of DKIM2 with no overlap.
• Pete Resnick: Are you saying the transition mechanism should be a necessary component of Bron’s draft to adopt the document?
• Jim Fenton: Yes, in the draft itself or in an Applicability Statement.
• John Levine: To Jim’s point, I agree we need to think about this. We should encourage signing with both. They should be separate protocols so you can sign with both, and even if you have only one signature you get the benefits of it (e.g., detecting replay). With DKIM, four signatures gives you four answers, while in DKIM2 a group of four signatures yields a single answer. That’s different enough that it’s not useful to see if we can shoe-horn these into DKIM. Trying to make that work isn’t a good use of our time.
• Dave Crocker: The statement that adoption of DKIM2 will take years will be more like a couple of decades, as that’s what we usually see. IPv6 ignored the transition from IPv4, and that one’s now been in progress for 30 years. Even with the market pressure of the big providers, there can be adoption barriers that turn out to be quite serious, but we’re not discussing that. The problem happening generally in this discussion is to say that trying to “stuff” things into existing DKIM is a problem. I haven’t suggested that. I’m saying the signing function works fine and all of these ideas are adding end-to-end functionality that extends DKIM without breaking it. Burying things in DKIM is an easy thing to do, but replacing a widely deployed signing engine doesn’t make sense, and assuming software upgrades happen well doesn’t comport with the history of the Internet.
• Arnt Gulbrandsen: Dave said what I wanted to say. The timeline we’re talking about here is decades.
• Bron Gondwana: I also agree with Dave about timelines; “years” is the best case. The best we can do is plant a tree now; we can’t plant it 20 years ago. Even on a scale of decades, it’s still worth doing. The signature at the first hop is the most interesting; it’s viable as it’s unchanged, so as long as the right stuff is signed, this gives us a cleaner upgrade path. My experimental DKIM2 code uses the DKIM signing engine and keys; there’s a lot of code reuse. Locking down the things that need to be signed is critical, but otherwise most of the stuff we need is already in DKIM.
• Pete Resnick: Murray and I are trying to follow along in the chat, and we’ll have to summarize it all to the list because I think we’re converging here. [ACTION: Chairs to review and summarize chat points to the list.]
• Bron Gondwana: In the chat people are asking about examples of ARC being checked.
• Richard Clayton: I don’t think there are more than 10-20 DKIM implementations in the world. Almost everyone I know has at least started from one of the open source libraries. “Updating the software” will require the work of a relatively small number of people. As Bron said, what we propose doesn’t change keys or canonicalization; large amounts of code can be recycled. There’s an example that produces DKIM and DKIM2 signatures in parallel. It’s not a vast amount of work to do this. Depending on what we do about multiple destinations, which is still an open topic, then MTA changes maybe required. There are more MTAs than there are DKIM implementations. Second, ARC is borderline useless. We’ve been trying to make use of it at work; many implementations lose track of the ARC chain or allow malicious mutations yet continue the chain. We will more likely terminate our ARC support rather than trying to fix it, and we need to move on from that. The large operators are keen to solve these problems and we’re looking to apply some pressure to make that happen by requiring authenticated mail and, eventually, DKIM2.
• Allen Robinson: I echo Richard’s view of ARC. It presumes trust in the signers to an unacceptable extent. Also echo Richard’s view of ease of implementation: I did ours over a weekend. The body processing didn’t change. Header hashing and signature generation changes in the sense that the list of fields that must be hashed is different, but otherwise DKIM2 and DKIM are syntactically the same. It doesn’t need a whole new implementation.
• Pete Resnick: This has been very valuable to me, and the topic of transition strategies is important.

Motivation Draft

• Murray Kucherawy: The call for adoption is closed. Are we good to go?
• Bron Gondwana: I don’t have a list of open issues. Happy to discuss anything people want to bring up about it.
• Dave Crocker: I noticed the name of this document changed, and the scope is considerably broader than what the title implies. The list of nine features that my table produces exemplifies that. I’m concerned with a tendency in discussion to conflate things down in that way. It hides the complexity of what this effort is trying to do. Also, the term “security gateway” is not a term of art and needs to be defined. The document could benefit some from reordering or consolidation of some of the material; some of this is editorial, some of it may be substantial.
• Bron Gondwana: Happy to reorganize it. As for scope, I’d be happy to discuss specific ideas. Certainly one thing that’s changed is the material around intended recipients, and there’s been some list discussion around this. I’ve tried to highlight the necessary properties and take design decisions out of it to keep it general, but this can be rolled back if that’s helpful.
• Murray Kucherawy: We are chartered to produce an applicability statement, which we could use to document a transition plan. We could start this now, or we could wait until there are a couple of interoperating implementations. (Nods and thumbs up in the room.)
• [ACTION: Confirm and complete adoption of the motivations draft.]

Other Drafts

• Pete Resnick: Are there other drafts we should talk about, for which we need editors, etc.?
• Bron Gondwana: Everything around DNS and bounce formatting and processing are key topics. They’re currently in separate documents. Up to the chairs how we process them.
• Jim Fenton: It’s been kind of an assumption here that DKIM2 is going to use compatible key records with DKIM. One thing I’m concerned about is post-quantum algorithms. Those algorithms typically involve really huge keys. We talked about them in places like DCRUP but I think we should revisit this; we have an opportunity to produce something that would accommodate PQ.
• Murray Kucherawy: You’re right, we did this with DCRUP. John Levine, how much adoption of ed25519 keys have we seen?
• John Levine: It rounds to zero, because RSA works just fine. Also current DKIM makes double signing kind of painful. Maybe we should consider what IIM did and put the key in the signature and a hash in the DNS. My guess is that DNSSEC will solve this before us anyway.
• Murray Kucherawy: Should we pick this up here, or do a DCRUP again?
• Andy Newton: How long will this take?
• Murray Kucherawy: We know how to do this, it’s just DCRUP again. But we’re not chartered to take up crypto work. Up to you.
• Andy Newton: My gut reaction is that it belongs here. I’ll think about this.
• Murray Kucherawy: We can always take words from the DCRUP charter.
• Allen Robinson: One of the motivations for reusing DKIM’s key management is that email service providers have a very difficult time convincing customers to do anything with DNS. Reusing DKIM RSA keys greatly reduces barriers to adoption. I think that’s separate from the question of whether DKIM2 could do something new with keys, like new algorithm types.

Any Other Business

• Bron Gondwana: A big open question is whether we should sign an explicit list of headers, or an explicit list of what not to sign and then sign everything else. We need a way to be able to see header fields that were added.
• Murray Kucherawy: As I recall in RFC 6376 we gave a specific list plus more general guidance that one should sign stuff that alters presentation. RFC 4871 had a very specific list but then we went to the more general guidance. We should document why we’re going back if that’s what we decide.
• Wei Chuang: I think we should do large key management here. I wonder how folks are planning on doing that in DNS. Also I agree with Dave’s earlier comment that we should re-examine what has to happen around re-doing headers and which have to be hashed. There are proposed alternatives on the list, but there’s also value in just keeping compatibility with existing engines. Discovery of newly added things is valuable. We should endeavor to create some examples.
• Bron Gondwana: If you always sign all headers all the time, then if you remove one, you have to describe that someplace or you can’t validate the signature.
• Wei Chuang: Being able to record changes to “h=” probably can accomplish this, or you need some other way to indicate major header changes.
• Richard Clayton: Signing headers is one area where existing code bases should be improved because at the moment to protect “Subject”, you have to over-sign it. Otherwise an attacker can add an extra, one of which is checked and the other of which is rendered (for example). I would like to see us signing every instance of a particular header. Second, should we allow people to specify their own list? I’m not a fan of this; people are sloppy about it, and we get poor security as a result. If you try to consult the registry to produce a good list of these, it’s a very long list, or it’s not complete as new fields get registered. We get once chance to change this so let’s do it in a future-proof way. The challenge for the diff/algebra feature is to add a succinct way to say “I added this custom header”, which is simpler or more tidy than having to do a general diff/algebra. Sorting is also a possible consideration.
• Bron Gondwana: It might be helpful for the diff algebra to be able to declare “I added a bunch of headers with this prefix.”
• Barry Leiba: The “tl;dr” version of what Richard said was “sign almost everything”, but we should do “sign everything completely”. Also the history for the list of header fields was that in RFC 4871 the list we gave was demanded by an AD, who was then not on the IESG the second time around. I think if we say “you must sign these header fields” then an implementation will either sign everything or sign only those. I suggest not trying to pick and choose or guess; just sign everything and be done with it.
• Bron Gondwana: The issue there is Received fields. It’s necessary to be able to see what was added.
• Murray Kucherawy: What about trace headers instead of Received?
• Bron Gondwana: That’s the idea. The challenge is learning what new trace headers may appear. Consulting a registry would be part of that process.
• Murray Kucherawy: EMAILCORE just updated the header field registry to make it clear which ones are trace fields.
• Barry Leiba: People will screw this up by not knowing which ones they are. Just sign everything and rely on the “figure out what changed” code. There’s value in Received.
• Dave Crocker: This is the operational anti-abuse WG. Most of you are familiar with Cory Doctorow’s proposal that says a FUSSP won’t work. It’s useful to be able to refer to this, and I’m now worried that this might disappear from his web site. Would people find it useful to make an RFC version of this for archival purposes?
• Pete Resnick: I think it would be useful and possibly exactly what Eliot would like to publish in the independent submission series.
• Jim Fenton: I kinda think that making an RFC for something is a high overhead way of making something archivable when cheaper ones exist, like archive.org.
• Dave Crocker: That’s a relatively obscure mechanism. It’s not convenient to access.
• Bron Gondwana: I think this is a great idea. The work in this WG ticks at least half the boxes in that chart. I agree with the ISE, don’t wait for April 1.
• Andy Newton: I asked the Security ADs about the PQ question, and they said to let TLS deal with it.
• Michael Hammer: I don’t see the PQ as critical in terms of backwards compatibility, but I do see it as a differentiator. Early adoption might be slower with DKIM2 using PQ, but it’s a driver in terms of adoption once we hit the PQ event horizon because it’s already baked in and used as a starting point.
• Jim Fenton: I’m puzzled by the SEC ADs answer. I don’t see what TLS adopting PQ has anything to do with DKIM.
• Murray Kucherawy: I tend to agree, but we’re also not in any hurry.
• Jim Fenton: I didn’t mean it’s urgent, but since we’re transitioning to a new signature format(s), it’s an opportune time to do so.
• Michael Hammer: I’m going to guess their point is that once it’s baked into TLS, there will be broader adoption rather than point solutions.
• Bron Gondwana: There’s really two choices here: Retain compatibility with existing keys, or do something more secure and modern, and then require that to play. There are merits to both paths. Happy to design for either. Algorithm dexterity will need to be designed in.
• Allen Robinson: It’s going to be such a huge barrier to adoption if DKIM2 requires deploying new keys for signing. It’s not about the algorithm; even demanding new RSA keys is so difficult for service providers to convince their customers to do anything. That’s a major motivator to reuse DKIM RSA keys to support DKIM2. This should be pushed out to some future date.
• Michael Hammer: I agree with Bron that this should be a point of discussion we should have. It’s not something we need today. The transition is going to be a long one either way.
• Wei Chuang: This speaks to the point that algorithm changes will raise interoperability or adoption challenges. Once we reach the PQ event horizon, then it makes a lot of sense for this WG or a later one to require this set of algorithms to be more resilient. I propose that at different time scales, we change; this support should be a SHOULD. Work upward from the legacy installed base.
• Michael Hammer: There’s already PQ algorithms out there. If we start out with a SHOULD then it becomes easy to make it a MUST and drop RSA when we hit that event horizon, rather than doing some hand-waving and dealing with it down the road. When that event horizon hits, there’s going to be a mad scramble in a lot of areas and DKIM won’t be a high priority for a lot of people.
• Pete Resnick: We should summarize this discussion and take it to the IESG for consideration. Please stay tuned for possible scheduling for an interim before Montreal. See you all there.

Adjourned 17:00.