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
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
