Hi Pete, Hi all, Sorry, Pete, but regarding <xref target="RFC2026" /> and <xref target="RFC2418" section="2.2" /> this is the duty of the authors and/or editors.
I have already provided a complete structural solution: a flattened JSON array layout to eliminate duplicate-key parsing differentials and guarantee predictable linear O(n) parsing time. If the authors refuse to fix a known, structural vulnerability (RFC 8259) in their text, the document lacks the necessary security architecture to achieve consensus. I expect the authors to integrate the flat array framework into the next revision. I am ready to do a review of the next revision. Regards, Timo It looks like Pete Resnick aimed to say: > On 15 Sep 2026, at 5:17, Timo Gerke wrote: > >> have you never had typos in mails? > > All of the time! I did not mean to cast aspersions; my apologies for > coming across that way. > >> The core problem with JSON schemas is that they just can't limit >> tag usage by design, as Richard said. >> >> Writing "MUST use the first tag" into the spec does not stop >> dangerous Parsing Differentials). Standard JSON parsers handle >> duplicate keys in an undefined manner (RFC 8259). > > Well, to be clear, 8259 says: > ``` > The names within an object SHOULD be unique. > > An object whose names are all unique is interoperable in the sense > that all software implementations receiving that object will agree > on > the name-value mappings. When the names within an object are not > unique, the behavior of software that receives such an object is > unpredictable. > ``` > (See RFC 2119 for what "SHOULD" means in this context.) > > So, if you create a non-interoperable recipe with non-unique names, it's > not going to interoperate. As we are often fond of saying in the IETF, > we are not the Internet Protocol Police: We tell you how to do the > interoperable thing, but we don't (and can't) enforce it. In this case, > if people make recipes with duplicate keys, there's a high likelihood > the signature will fail and the message will bounce. I'm not sure that's > a bad thing. > > So, where is the problem here that needs to be addressed? > >> A flattened JSON array forces strict sequential determinism. >> It ensures that duplicate context tags cannot overwrite each >> other or create ambiguous parsing paths. > > Are you asking for a "JSON array", or are you saying you want to flatten > the JSON into an array of a different format? I think (as I've asked > before) you will really need to propose text to replace what is in > draft-ietf-dkim-dkim2-spec and see if you can garner consensus around > it. Right now, I am not seeing that. > >> Regarding predictable parsing time: Sterile lab setups do not >> simulate a CRITIS gateway under a DDoS attack. Deeply nested JSON >> opens the door to algorithmic complexity exploits. An array >> guarantees linear O(n) parsing time at wire speed. > > Nor do claims of theoretical exploits mean that they are necessarily a > practical problem that needs to be addressed. > >> My idea of a flat array reduces the attack surface to the >> smallest possible level. It provides security by design, rather >> than security by policy. > > So again, I am not seeing others on the list supporting this position. I > don't think further explanation of your position is needed; I think your > concern is well understood. Your task now is to actually present > alternative text to what is in the current version of the spec and see > if others agree that your proposed solution is better. Until you provide > alternate text for the document, I have to consider this discussion > closed. > > pr > >> It looks like Pete Resnick aimed to say: >>> On 14 Sep 2026, at 11:34, Timo Gerke wrote: >>> >>>> To me it seems that you lost the core of my idea. >>> Well, that may be true! >>> >>>> Richard was indeed talking about duplicate JSON tags (key-value >>>> pairs). The point is, that if we do not use key-value objects >>>> and instead transit to a flattened, sequential JSON array, >>>> there just can't exist any duplicate JSON tags in the data. >>> Well, that is a different point than you made earlier: You had said >>> "Since my idea does not save keys in the JSON data..." and "...we >>> should >>> consider beleving keys in DNS." So it sounds like we are agreed that >>> crypto keys are not intended to be in JSON and are not part of the >>> concern. >>> >>> But on this new point: I think you have one too many "not" in that >>> sentence, but if I understand you correctly, you are concerned about >>> duplicate JSON key values. But as Richard said, the spec can properly >>> limit that, so I don't see the concern. >>> >>>> A flattened array is also able to be parsed in predicable time. >>> As Hannah and others have pointed out, CPU/time concerns do not seem >>> to >>> be an issue to those who have already tried implementing some of >>> this. >>> Unless you have a practical counter-example, I think I must conclude >>> that this has been reasonably considered by the group. >>> >>>> And mathematically it is nearly impossible to generate >>>> identical SHA-512 hashes from different data anyway. >>> I'm not sure what concern this is supposed to be about. >>> >>> 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 > 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]
