Minutes of the DKIM Working Group

IETF 125 – Shenzhen, China
2026-03-20 01:00Z
Chairs: Pete Resnick (present), Murray Kucherawy (regrets)

Meeting started at 01:01.

Pete presented standard administrivia:

• Note Well slides
• Participation Guidelines/Tips
• Agenda -- Bron requested a short document status update; no other proposed changes.

Pete reviewed the status of current and proposed working group documents:

• draft-clayton-dkim2-spec is the primary document going forward; draft-ietf-dkim-dkim2-header has been folded into that.
• We will keep draf-ietf-dkim-dkim2-motivation around to become the BCP document.
• Related documents were reviewed and will be reviewed by the Chairs and handled.
• The Brotman documents should be handled, but this will be deferred until the working group is prepared to discuss reporting.
• Todd Herr’s BCP document can be updated as we go along. It should be a WG document.

Richard Clayton: “Current Thinking on DKIM2” and discussion of the state of draft-clayton-dkim2-spec-08 issues:

• No need for the hashes to be in a JSON structure.
• No need for a versioning scheme; they never work anyway.
• Bron: I have implemented the above and it works fine.
• Sign all header fields except Received, Return-Path, X-*, DKIM-Signature, and ARC-*.
• Concatenation occurs in natural sorted order.
• Pete: Why not just sign everything?
• Richard: Internal relaying causes more Received fields to appear, which can be a problem.
• Barry: What happens if more exceptions need to be added later? A specific list of things to sign, or “sign everything” would be preferable. Also, prefer to sign bottom up because that’s how fields get added.
• Bron: Sorting deals with the bottom-up ordering problem. Also Message-Instance and DKIM2-Signature should be listed there. I could live with having to sign X-* fields and leaving operators to sort out what they mean. Message-Instance could list what it’s not covering.
• Richard: I don’t know why you would sign Received. It has no security properties. You would need to include a recipe indicating that the field was added.
• Bron: We want to declare what we’re not signing. That approach scales better.
• Barry concurred with the last point.
• Alexey: +1 to Bron’s point. Also a lot of MUAs still add X-Mailer.
• Pete: You never know what the eventual security properties of a header field are.
• Richard: You never see Return-Path on the wire anyway.
• Barry: Say “These fields are commonly not signed” rather than making it normative.
• Pete: That could go in the BCP?
• Barry: Not necessarily.
• Tero: Received has security properties; spam filters, for example, care what they claim.
• Richard: If you trust Received fields, you’re in a pretty bad place.
• Recipes use JSON. There’s a schema proposed; we’re hacking on the details.
• Chat discussion supported a bottom-up expression of some kind.
• Bron volunteered to write up a schema amendment to support this.
• DKIM2-Signature tags were reviewed. Reminder that the key/selector system of DKIM is reused. A deeper dive into the signature tag was provided.
• Supplementary discussion of the mechanics of signature generation. Bron indicated that he’s happy with this version.
• Encoding of SMTP envelope parameters (MAIL FROM, RCPT TO) into the signature in JSON was discussed. This is needed to deal with the replay problems. However, these values can confuse tag-value parsers.
• Bron: JSON appears to be the most resilient solution to this.
• Wei: Encoding with base64 would obscure the value, which also obscures alignment. We need to see these values for debugability.
• Bron: Agreed that this makes the headers harder to read for a human, but it would be easy to write a tool to do it.
• Ken concurred with JSON.
• Allen begrudgingly supports continuing on the JSON path, not having found a better alternative.
• Pete felt consensus exists to support JSON as the path forward.
• Discussion of results. DKIM returned one of three things, Authentication-Results allows for seven things. Which model should DKIM2 embrace, and how should we advise SMTP responses to be generated?
• Barry advocated for ensuring the output of the verification process is clear about what that output is telling us, and avoid adding nuances.
• Wei supports ensuring that specific reasons for failures are provided for in the exchange between actors, to support interoperability and debugging.
• Pete pointed out that the enhanced status codes registry is certainly available for us to provide finer details.
• Wei hopefully the answers to all of this will come out in interop testing.
• Tags in key records were reviewed. Proposal to consider deprecating the h, s, n, and t tags.
• Allen expressed concern about re-use of tags.
• Pete suggests a wider survey should be done, or more data collected, before we can decide.

Pete discussed future interims, to be scheduled monthly or so, at the same day and time (Wednesday 1:00pm Pacific time) as the previous one. There were no objections and some expressions of support in the room.

Meeting adjourned at 02:38.