Hi Bron, all, Point taken. Let's focus strictly on wire size, parsing risks, and actionable guardrails.
Think about millions of queries a minute. DNS caching (TTL) efficiently handles day-to-day traffic but provides no protection against adversarial cache-bypassing traffic (randomized selectors/subdomains). For large-scale inbound operations in highly critical infrastructure, unregulated JSON introduces severe vectors like JSON bombs (recursion DoS) and parser differentials, while verbose keys risk forcing DNS-over-TCP fallbacks. Regardless of the format, we need a dedicated Key Validity Property (e.g., "e" for expiration) holding a uint64_t UNIX timestamp, independent of individual signature lifetimes (x=). To balance robust structure and high-security compliance, the specification must enforce either: - Strict Inline Guardrails: A maximum nesting depth of 1 (strictly flat) and single-character tokenized keys. - Alternative Paths: Offloading via an HTTPS URI (the BIMI / mailmaint approach) or keeping the native flat plaintext of DKIM1. To validate these architectural paths and deployment risks before the document leaves the WG, I suggest considering requesting an early review either from ARTART or TSVART. It is probably easier to fix these transport, filter, and parser risks today than having to immediately start drafting DKIM3 tomorrow. Best regards, Timo Am 04.09.26 um 04:48 schrieb Bron Gondwana: Hi Timo, Please review the arguments that were made at the time the JSON structure was introduced and address the quoting complexities and likelyhood of subtle incompatibilities compared to using an existing structured format. JSON was chosen because it has a very well defined structure with widespread availability of compatible parsers. You also made quite a few random points and detours into unrelated protocols, which makes it hard to extract an actionable technical proposal from your message. Regards, Bron. -------- Original Message -------- Subject: [Ietf-dkim] Re: Proposal key validity field vor DKIM2 Date: Friday, September 4, 2026 at 02:48 UTC From: Bron Gondwana <[email protected]> To: [email protected] >> Hi all, >> >> Looking at the current direction of DKIM2 and JSON structures, I >> have to ask: Are we quietly trying to invent JNS (JSON Name >> Service) next? >> >> Unless, of course, someone suggests using YAML instead... though >> given its parsing quirks, I think I would prefer suing YAML! >> Personally, I still prefer IMAP5. And let's be honest, nobody >> would ever dare to write an SMTP2 draft as long as JCK is active >> and we all know his motto is rather "less is less", and I follow >> the same strategy. >> >> Making a mistake in early drafts by introducing JSON might be >> human, but persisting with complex, structured formats in the >> message transport layer despite the clear performance costs is >> diabolical. A clean and lean API is worth so much more. To keep >> DKIM2 secure against parsing overhead and DNS-over-TCP fallbacks, >> we should strictly enforce flat, native tag-value representations >> instead of JSON/YAML structures. >> >> Specifically, we need a dedicated field for Key Validity: >> >> - We need a separate tag to signal when a key itself expires, >> independent of the signature's expiration (x=). >> >> - To avoid the Year-2038-problem on legacy 32-bit hardware, we >> also should think about setting the datatype of the signature >> expiration and the key expiration field to uint64_t. >> >> Best regards, >> >> Timo >> >> -- >> 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 >> >> _______________________________________________ >> Ietf-dkim mailing list -- [email protected] <mailto:ietf- >> [email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]> >> >> >> *Attachments:* >> >> * OpenPGP_0x9F03DF9F597BF31E.asc >> * OpenPGP_signature.asc -- Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC [email protected] _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected] -- 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
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
