Hi Timo, What format would you propose instead of JSON? If your concern is performance, modern JSON parsers using SIMD instructions can parse a complex DKIM2 recipe in nanoseconds, so I doubt the format itself would be a bottleneck. If your concern is security, wouldn't writing and maintaining a parser for a custom serialization format introduce more security risk than relying on a battle tested, widely audited JSON parsing library?
Regarding the key validity field, you raised concerns about key rotation. Could you clarify why a rotated key no longer being present in the DNS records isn't sufficient on its own? If the field's purpose is logging, does that justify the added complexity of bloating the DKIM2 signature with an extra field? Best, Mauro > On 11 Sep 2026, at 5:43 pm, Timo Gerke <[email protected]> wrote: > > Hi Pete, > > Here are the individual answers to your questions: > > - Are you objecting to recipes in general, or are you only > objecting to JSON-encoded recipes? > > I am objecting to the current architecture of recipes that allows > structural state manipulation on the transport layer. Encoding > this structural complexity in JSON is compounding the risk. > > The specific parsing differential unique to JSON here is the lack > of strict object-key ordering and duplicate key handling in > standard JSON specs. If a Milter parser evaluates a nested recipe > payload differently than the downstream MTA engine, the > cryptographic canonicalization is shattered. 15 years of DKIM1 > proved that flat, native tag-value structures are inherently > immune to this exact category of serialization differentials. Why > did DKIM1 work without JSON for 15 years? > > - What text do you want to add to what section of what document? > [Regarding y2k38] > > This is not a matter of a local text patch in the Security > Considerations. The wire format specification itself needs to > enforce strict boundaries. If timestamp and expiry tags are not > explicitly bound to deterministic datatypes (like uint64_t > equivalency) on the wire, the protocol invites overflow > vulnerabilities on legacy architectures. > > - Do you see DKIM as securing critical infrastructure? Please > explain. > > Yes, absolutely. Global email transport is critical nfrastructure > (CRITIS). National grid operators, public administrations, and > educational networks rely on DKIM to protect their core > communications from spoofing and manipulation. Designing an > internet standard under the assumption that it does not secure > critical infrastructure is a fundamental violation of OWASP Top > 10: Insecure Design principles. > > - This is not a discussion I'm willing to have on this list. > I'll write to you separately about this topic. [Regarding > Running Code] > > Pete, to me it seems you do not like qualified architectural > discussions on list. > > Did you forget the fundamental rules the IETF was built on: "We > believe in Rough Consensus and Running Code."? But actually, > there is no running code. Defining Rough Consensus while > bypassing the reality of broken implementations at the edge nodes > degrades a core IETF principle into theoretical debate. > > - As the editor of RFC 5322, I can tell you that the parsing > differentials between 5322 parsers make parsing differentials > between JSON parsers look downright quaint... > > Arguing that we should introduce nested JSON parsing > differentials into the transport layer just because legacy RFC > 5322 parsers are already structurally flawed is an architectural > fallacy [RFC 5322, OWASP-Richtlinien zu Insecure Design]. We > should minimize parsing complexity at the trust boundaries, not > compound it. You SHOULD consider consulting John Klensin. > > - I'm not sure what you're referring to. Please cite a specific > message. > > I am referring to Bron's explicit acknowledgment on this list > regarding the operational failure of the current design at > inbound edge gateways. > > BTW: Bron already confirmed that this design would possibly not > work on Inbound Edge Gateways. If the recipe model cannot survive > the reality of inbound boundary validation, the design is > fundamentally faulty. > > Operators in the real world require deterministic security, not > administrative consensus. > > Regards, > > Timo > > It looks like Pete Resnick aimed to say: >> Hi Timo, >> >> Please answer the below questions individually. Copy and paste them into >> your answer if you need to. >> >>> On 10 Sep 2026, at 15:59, Timo Gerke wrote: >>> >>> Shifting Parsing Differentials to the Security Considerations >>> section is the administrative equivalent of putting a warning >>> label on a structurally flawed bridge instead of fixing the >>> engineering. If a design inherently allows two compliant parsers >>> to interpret the same wire format differently, the cryptographic >>> canonization is broken by design. This cannot be patched in >>> prose. >> >> Are you objecting to recipes in general, or are you only objecting to >> JSON-encoded recipes? >> >> If the latter, please describe the parsing differential that occurs from >> JSON-encoded recipes that would not also occur in any other encoding of >> recipes. >> >> If the former, then I don't see enough support for your objection to >> consider the rough consensus to be broken. >> >>> Regarding internal representation and y2k38: This is not about >>> internal code; it is about strict constraints on the wire format. >> >> What text do you want to add to what section of what document? >> >>> If a protocol aims to secure critical infrastructure... >> >> Do you see DKIM as securing critical infrastructure? Please explain. >> >>> ...running >>> legacy 32-bit hardware, leaving timestamp boundaries "out of >>> scope" is a known operational risk that flat, native types can >>> easily avoid. >> >> What text do you want to add to what section of what document? >> >>> Finally, defining Rough Consensus while bypassing the reality of >>> broken Running Code at the edge nodes degrades a core IETF >>> principle into theoretical debate. >> >> This is not a discussion I'm willing to have on this list. I'll write to >> you separately about this topic. >> >>> You are confusing me. As editor of RFC 5322 you should be the >>> last one who supports complex JSON objects in mail headers. >> >> As the editor of RFC 5322, I can tell you that the parsing differentials >> between 5322 parsers make parsing differentials between JSON parsers >> look downright quaint, and let's not even start down the path of MIME >> parsing. You're going to have to come up with specific issues that are >> of concern, not generalities, if you want to convince others on this >> list that there is a problem worth considering. (And my thoughts as >> editor of RFC 5322 are independent of my role as chair, which is to >> judge the rough consensus on the list.) >> >>> BTW: Bron already confirmed that this design would possibly not >>> work on Inbound Edge Gateways. >> >> I'm not sure what you're referring to. Please cite a specific message. I >> know Bron (among others) has said that some of the actions of inbound >> edge gateways are not appropriate for recipes, but I have no idea how >> that is relevant to the current discussion. Please provide context. >> >> pr > > > Timo Gerke > Hamburg, Germany > > "If you think technology can solve your security > problems then you don't understand the problems > and you don't understand the technology." > -- Bruce Schneier > <OpenPGP_0x9F03DF9F597BF31E.asc> > _______________________________________________ > Ietf-dkim mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
