I heard that!
", "time": "2026-01-28T21:00:05.000Z"}, {"author": "Lori Blair", "text": "Yay! I heard things :D
", "time": "2026-01-28T21:02:27.000Z"}, {"author": "Bron Gondwana", "text": "Hello!
", "time": "2026-01-28T21:02:44.000Z"}, {"author": "Lori Blair", "text": "Hey Bron! So glad I saw this email alert :D
", "time": "2026-01-28T21:03:13.000Z"}, {"author": "Bron Gondwana", "text": "I have uploaded them - they're the slides from Richard, but I can talk to them with him not here
", "time": "2026-01-28T21:04:14.000Z"}, {"author": "Murray Kucherawy", "text": "Thanks!
", "time": "2026-01-28T21:04:24.000Z"}, {"author": "Murray Kucherawy", "text": "Slides approved and available.
", "time": "2026-01-28T21:05:00.000Z"}, {"author": "Lori Blair", "text": "Yes!
", "time": "2026-01-28T21:06:21.000Z"}, {"author": "Lori Blair", "text": "I've taken minutes many times before
", "time": "2026-01-28T21:06:43.000Z"}, {"author": "Lori Blair", "text": "https://notes.ietf.org/notes-ietf-interim-2026-dkim-01-dkim
", "time": "2026-01-28T21:07:04.000Z"}, {"author": "Murray Kucherawy", "text": "https://notes.ietf.org/notes-ietf-interim-2026-dkim-01-dkim
", "time": "2026-01-28T21:07:10.000Z"}, {"author": "Murray Kucherawy", "text": "Argh, too slow.
", "time": "2026-01-28T21:07:14.000Z"}, {"author": "John Levine", "text": "Happy to let Lori do the work
", "time": "2026-01-28T21:07:58.000Z"}, {"author": "Murray Kucherawy", "text": "Thank you, Lori!
", "time": "2026-01-28T21:08:03.000Z"}, {"author": "Dave Crocker", "text": "Bron - closer to your mic please
", "time": "2026-01-28T21:09:15.000Z"}, {"author": "Murray Kucherawy", "text": "So Richard stole Bron's content, and Bron stole Richard's slides. In a WG about content integrity.
", "time": "2026-01-28T21:11:20.000Z"}, {"author": "Dave Crocker", "text": "Content integrity is not the same as process integrity.
", "time": "2026-01-28T21:12:44.000Z"}, {"author": "Dave Crocker", "text": "The problem with an inclusive list is that it will be very, very, very long, given the exhcnage I had with Richard, long ago.
", "time": "2026-01-28T21:17:06.000Z"}, {"author": "Dave Crocker", "text": "What has been missed from discussion is the /reason/ for including or excluding. What is the 'theory' driving this.
", "time": "2026-01-28T21:17:37.000Z"}, {"author": "Dave Crocker", "text": "My own suggestion was a registry for any header-field that contains 'security-related' info. Not all header fields matter.
", "time": "2026-01-28T21:18:11.000Z"}, {"author": "Murray Kucherawy", "text": "I think I liked the future-proof nature of abstract advice rather than a hard list. The downside is that this seems to confuse people or risk they'll get it \"wrong\".
", "time": "2026-01-28T21:18:17.000Z"}, {"author": "Dave Crocker", "text": "'advice' is not a deterministic process for signer and validator.
", "time": "2026-01-28T21:18:40.000Z"}, {"author": "Murray Kucherawy", "text": "This would be a peculiar use of a registry, I feel.
", "time": "2026-01-28T21:18:41.000Z"}, {"author": "Dave Crocker", "text": "@murray, seems pretty common, to me.
", "time": "2026-01-28T21:19:05.000Z"}, {"author": "Murray Kucherawy", "text": "@Dave: It should be, but I agree it is not.
", "time": "2026-01-28T21:19:09.000Z"}, {"author": "Murray Kucherawy", "text": "Registries are for code points, I thought, which this is not. Also, wouldn't updating the registry immediately render some percentage of implementations non-interoperable?
", "time": "2026-01-28T21:20:33.000Z"}, {"author": "Murray Kucherawy", "text": "The same message signed by two different signer who last checked the registry on different dates won't yield the same result.
", "time": "2026-01-28T21:21:09.000Z"}, {"author": "Murray Kucherawy", "text": "signers*
", "time": "2026-01-28T21:21:16.000Z"}, {"author": "Bron Gondwana", "text": "It's fine IFF you include the signed list with the signature
", "time": "2026-01-28T21:21:39.000Z"}, {"author": "Dave Crocker", "text": "\"if you start trusting the headers\" is not the same as \"if you start trusting a field that was not included in the signature.
", "time": "2026-01-28T21:21:41.000Z"}, {"author": "Dave Crocker", "text": "@murray, there is a registry for header fields. In any event, knowing what fields to include or exclude sure sounds like code-point stuff to me.
", "time": "2026-01-28T21:22:30.000Z"}, {"author": "Pete Resnick", "text": "Yes, sloppily said on my part.
", "time": "2026-01-28T21:22:33.000Z"}, {"author": "John Levine", "text": "I find the argument about the length of the list unpersuasive. Message headers are already so huge that a few thousand more characters is noise.
\nI would say that we only mention each header name once, and you sign all of them.
@murray, yes, an ability to ensure synch is important. Back when I discussed this with Bron, my thought was for including the date/time the registry was consulting, on the theory that every entry timestamps when it was created...
", "time": "2026-01-28T21:25:00.000Z"}, {"author": "Dave Crocker", "text": "@john, if that can work, it is the simplest and safest. In previous discussion, it sounded as if the list would be too long.
", "time": "2026-01-28T21:25:56.000Z"}, {"author": "Pete Resnick", "text": "@John Levine: Do I list everything that I have signed and everything I know did not exist?
", "time": "2026-01-28T21:26:00.000Z"}, {"author": "John Levine", "text": "@Dave Crocker having to keep a complete history of the registry with time stamps to validate a signature? Urrgh
", "time": "2026-01-28T21:26:10.000Z"}, {"author": "John Levine", "text": "@pete you list what you signed.
", "time": "2026-01-28T21:26:40.000Z"}, {"author": "Pete Resnick", "text": "Do I list what I didn't sign?
", "time": "2026-01-28T21:26:57.000Z"}, {"author": "John Levine", "text": "In the sense that there were no headers of that type, I suppose so
", "time": "2026-01-28T21:27:13.000Z"}, {"author": "Dave Crocker", "text": "@john, not a 'complete history'. Each entry in the registry has a timestamp of when the entry was added. Signer cites a timestamp which means its signature is subject to all the header fields listed pror to that time.
", "time": "2026-01-28T21:27:19.000Z"}, {"author": "Pete Resnick", "text": "Do I list what exists but I didn't sign?
", "time": "2026-01-28T21:27:33.000Z"}, {"author": "John Levine", "text": "@pete no
", "time": "2026-01-28T21:27:39.000Z"}, {"author": "R. Latimer", "text": "My objection to RCPT TO isn't the signing, it needs to be done, it's with how it's transmitted, leading to O(N) regressions in signing, storage and data use.
", "time": "2026-01-28T21:29:06.000Z"}, {"author": "R. Latimer", "text": "And precludes certain existing use cases that are explicitly permitted with DKIM.
", "time": "2026-01-28T21:30:18.000Z"}, {"author": "Pete Resnick", "text": "(with no hat) +1 Dave. We need to be more precise.
", "time": "2026-01-28T21:31:35.000Z"}, {"author": "Dave Crocker", "text": "Core minimum, with additions permitted for creator is a common model.
", "time": "2026-01-28T21:36:01.000Z"}, {"author": "Murray Kucherawy", "text": "I think my position on the first point is that (a) forcing the single signer thing, if that's consensus, just needs to be very clearly explained. It's a major change from SMTP's long-standing advice about not doing that.
", "time": "2026-01-28T21:36:37.000Z"}, {"author": "Dave Crocker", "text": "However, not specifying that core in each list for a message relies on defaults, which does not work so well.
", "time": "2026-01-28T21:36:43.000Z"}, {"author": "Murray Kucherawy", "text": "And (b) the privacy considerations of actually recording the invisible recipients also needs a thorough treatment.
", "time": "2026-01-28T21:37:01.000Z"}, {"author": "Pete Resnick", "text": "Why would the a server not want to sign any header it added?
", "time": "2026-01-28T21:37:19.000Z"}, {"author": "Bron Gondwana", "text": "Pete: it's more \"pointless headers added by intermediate systems break signature\"
", "time": "2026-01-28T21:37:45.000Z"}, {"author": "Pete Resnick", "text": "(including the originating server)
", "time": "2026-01-28T21:37:48.000Z"}, {"author": "Bron Gondwana", "text": "sender should list everything it adds for sure
", "time": "2026-01-28T21:38:02.000Z"}, {"author": "Dave Crocker", "text": "@murray, sorry, i'm not tracking what you mean, and suspect it takes discussion, not just anothyer posting.
", "time": "2026-01-28T21:38:03.000Z"}, {"author": "Pete Resnick", "text": "If an intermediate server adds a pointless header, it signs it.
", "time": "2026-01-28T21:38:33.000Z"}, {"author": "Lori Blair", "text": "should I be attributing who said what in the notes?
\nAlso don't judge me these will need some clean up
", "time": "2026-01-28T21:38:35.000Z"}, {"author": "Tobias Herkula", "text": "not a fan of dkim1-dkim2 interop, it will only provide an excuse to not upgrade timely
", "time": "2026-01-28T21:39:00.000Z"}, {"author": "Pete Resnick", "text": "(And describes its changes)
", "time": "2026-01-28T21:39:09.000Z"}, {"author": "Lori Blair", "text": "I'd argue for maybe a planned roll out
", "time": "2026-01-28T21:39:20.000Z"}, {"author": "Pete Resnick", "text": "@Lori: If you can attribute, that would be useful.
", "time": "2026-01-28T21:39:32.000Z"}, {"author": "Andrew Newton", "text": "The IESG?
", "time": "2026-01-28T21:39:35.000Z"}, {"author": "Dave Crocker", "text": "oh. single /recipient/.
", "time": "2026-01-28T21:39:46.000Z"}, {"author": "Andrew Newton", "text": "I doubt the IESG would have an issue unless this surfaces in IETF LC.
", "time": "2026-01-28T21:40:32.000Z"}, {"author": "Murray Kucherawy", "text": "Yeah the \"one recipient per message\" bit.
", "time": "2026-01-28T21:40:34.000Z"}, {"author": "Murray Kucherawy", "text": "@Andy: That's unfortuante.
", "time": "2026-01-28T21:40:51.000Z"}, {"author": "Murray Kucherawy", "text": "(but is also because I'm not there anymore ;) )
", "time": "2026-01-28T21:41:01.000Z"}, {"author": "Murray Kucherawy", "text": "I would definitely complain about this if it were under-explained.
", "time": "2026-01-28T21:41:15.000Z"}, {"author": "Lori Blair", "text": "if folks wouldn't mind going through the notes and adding their attributions that I missed I would appreciate and make sure I've accurately recorded what you've said
", "time": "2026-01-28T21:41:31.000Z"}, {"author": "Murray Kucherawy", "text": "@Lori: Wilco, thanks for getting us that far!
", "time": "2026-01-28T21:41:49.000Z"}, {"author": "Richard Clayton", "text": "the list of what was signed is what is was in the message you just got
", "time": "2026-01-28T21:45:32.000Z"}, {"author": "Dave Crocker", "text": "This 'interoperability' topic is about gatewaying between hetergeneous services.
", "time": "2026-01-28T21:49:46.000Z"}, {"author": "Murray Kucherawy", "text": "@Dave: Does \"heterogeneous services\" mean across protocol gateways (X.400, for an absurd example) or just across distinct DKIM implementations?
", "time": "2026-01-28T21:50:49.000Z"}, {"author": "Dave Crocker", "text": "'security relevant'. What are the criteria to qualify as relevant? Where is this documented? What is the basis for classing it/them as security relevant?
", "time": "2026-01-28T21:50:52.000Z"}, {"author": "Dave Crocker", "text": "@murray, DKIM1 and DKIM2 are different services. So by gatewaying, I'm classing their interoperability as equivalent to connecting X.400 to Internet mail, or the list. (Hmmm. Also connecting IPv4 environments to IPv6 services.)
", "time": "2026-01-28T21:52:26.000Z"}, {"author": "Murray Kucherawy", "text": "@Dave: Ah, thanks. I'd lost context.
", "time": "2026-01-28T21:52:48.000Z"}, {"author": "Murray Kucherawy", "text": "We dealt with this (what Pete is talking about) in Auth-Results at the receiver by enabling \"policy\" results. The classic example was \"This signature was good, but you didn't sign Subject, so we're failing it.\"
", "time": "2026-01-28T21:55:50.000Z"}, {"author": "Pete Resnick", "text": "For the record, I'm saying sign everything that you are sending.
", "time": "2026-01-28T21:56:48.000Z"}, {"author": "Lori Blair", "text": "people do put abuse contacts in x-headers at some ESPs
", "time": "2026-01-28T21:59:37.000Z"}, {"author": "Lori Blair", "text": "Also i'm not sure it's a bad thing DKIM2 definitively being last
", "time": "2026-01-28T21:59:55.000Z"}, {"author": "Tobias Herkula", "text": "adding headers is a change, so needs to be added in the modification data
", "time": "2026-01-28T22:01:22.000Z"}, {"author": "Tobias Herkula", "text": "yes and no, only look at the modification data, but no need to validate in between hop sigs
", "time": "2026-01-28T22:03:22.000Z"}, {"author": "Dave Crocker", "text": "Citations requested.
", "time": "2026-01-28T22:08:17.000Z"}, {"author": "Dave Crocker", "text": "And 'security-related' damage documentation also requested.
", "time": "2026-01-28T22:08:40.000Z"}, {"author": "Lori Blair", "text": "I could also possibly see malicious actors trying to DDoS the DKIM2 verification system by sending emails with tons of X- headers
", "time": "2026-01-28T22:09:20.000Z"}, {"author": "Dave Crocker", "text": "The goal of preventing bad actors from doing certain things has to deal with the reality of imperfection. The goal will never be attained. So the question is why effort to prevent /specific/ behaviors is worthwhile.
", "time": "2026-01-28T22:10:22.000Z"}, {"author": "Lori Blair", "text": "out of curiosity when is this scheduled to?
", "time": "2026-01-28T22:12:58.000Z"}, {"author": "John Levine", "text": "two hours
", "time": "2026-01-28T22:13:12.000Z"}, {"author": "Lori Blair", "text": "yes I am so sorry I need to run as well, I only had an hour
", "time": "2026-01-28T22:15:05.000Z"}, {"author": "Lori Blair", "text": "super fascinating :D
", "time": "2026-01-28T22:15:08.000Z"}, {"author": "Lori Blair", "text": "if someone can take over notes
", "time": "2026-01-28T22:15:14.000Z"}, {"author": "Dave Crocker", "text": "rfc6648:
\nRecommendations for Creators of New Parameters
\nCreators of new parameters to be used in the context of application
\n protocols:
SHOULD assume that all parameters they create might become
\n standardized, public, commonly deployed, or usable across
\n multiple implementations.
SHOULD employ meaningful parameter names that they have reason to
\n believe are currently unused.
SHOULD NOT prefix their parameter names with \"X-\" or similar
\n constructs.
If there is a set of headers that MUST be signed, why can't that be said in the doc in addition to a dynamic list of headers that are or are not to be signed?
", "time": "2026-01-28T22:24:51.000Z"}, {"author": "Dave Crocker", "text": "Suggestion:
\nStart by writing the principles for what to sign and what not to sign and why. No reference to specific fields. Just a 'security-related' discussion that defines that nature and seriousness of the threats that are of concern. What happens if the concern is not satisified? How much better will things be if they are?
", "time": "2026-01-28T22:24:57.000Z"}, {"author": "Dave Crocker", "text": "ps. the DKIM wg chartering was delayed because some IETF security geeks suddenly demanded a threat analysis.
", "time": "2026-01-28T22:25:49.000Z"}, {"author": "Brian Godiksen", "text": "Another example of a real world case where a sender might sign an X- header today is the CSA which asks senders to do so - https://certified-senders.org/wp-content/uploads/2019/10/CSA-Compliant-Mail-Headers_Update.pdf
", "time": "2026-01-28T22:26:05.000Z"}, {"author": "R. Latimer", "text": "JSON arrays are ordered, nothing else is guaranteed.
", "time": "2026-01-28T22:33:17.000Z"}, {"author": "Andrew Newton", "text": "Is the proposal to sign the JSON?
", "time": "2026-01-28T22:34:16.000Z"}, {"author": "Tobias Herkula", "text": "I'm fine with other textual formats, json was only the first one in my mind because i handle json day in day out
", "time": "2026-01-28T22:35:59.000Z"}, {"author": "John Levine", "text": "@brian CSA should register CSA-Complaints which is very easy. X-CSA-Complaints was a mistake
", "time": "2026-01-28T22:36:00.000Z"}, {"author": "Tobias Herkula", "text": "@john and the perfect example for the rfc6648
", "time": "2026-01-28T22:36:32.000Z"}, {"author": "Pete Resnick", "text": "\"parsing turducken\". Technical term of the day!
", "time": "2026-01-28T22:37:40.000Z"}, {"author": "Michael Hammer", "text": "ParsingvTurducken... I love it.
", "time": "2026-01-28T22:37:48.000Z"}, {"author": "Andrew Newton", "text": "Thanks to the Chairs.
", "time": "2026-01-28T22:44:09.000Z"}]