Hi Hannah, Thanks for the feedback! You are entirely right about the DNS layer staying conservative — my bad there.
The core issue lies within the message transport layer (the email headers). Introducing nested JSON structures for recipes creates significant validation risks at the Milter level. Even with stable parsers, you cannot eliminate Parsing Differentials. If two compliant parsers (e.g., Milter vs. downstream MTA) interpret a nested JSON object differently - like key ordering or duplicate keys—the cryptographic canonization breaks completely. This is a classic Insecure Design vector. Regarding y2k38 and expiration: Leaving representation "out of scope" is a risk for critical infrastructure running legacy 32-bit hardware. Relying on transient DNS deletion also ignores long-term immutable archiving, where historic signatures must remain deterministically verifiable independent of active DNS states. Since Bron already admitted the current "gummiband" design breaks at the edge nodes, there is no functional Running Code here. And without running code, there is no Rough Consensus for spec-06. Best, Timo It looks like Hannah Stern aimed to say: > Hi! > > On 9/2/26 23:05, Timo Gerke wrote: >> 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? > I'm a bit late to the game, but where are you seeing this? The DNS key > format draft is quite conservative, adding no fields to DKIM1 keys and > even deprecating a few, keeping the DNS record fully in tag-value syntax. >> [...] >> >> 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. > To me this reads like hyperbole. Have you benchmarked JSON parsers > recently? >> 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. > As said, DNS is tag-value. >> 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=). > Why? When a key expires, I'd expect it to be removed from DNS (or > replaced by an explicit revocation). >> - 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. > The timestamp field (t= in DKIM2-Signature, again in plain tag-value > syntax) is already specified with a ridiculously high limit, very far > from y2k38 issues. Signature expiry is specified to default to 2 weeks > after t=, and thus also y2k38 safe. > > How an implementation represents large t= values is out of scope for a > specification text. For my sake, yes, it can use u64, but it could also > decide to use strings or an array of 6 times u8, as long as it supports > the range mentioned in the spec. > >> [...] > Hannah. 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]
