On 11 Sep 2026, at 11:42, Timo Gerke 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.
First, let me say that you are the only one to be making the argument
that there is security risk involved; even Vittorio, who objects on
complexity grounds, is not claiming that. So I really don't see other
support for this position. And while you don't say so above, your
message in reply to Mauro makes it clear that this is not about JSON in
particular, but any encoding that would not strictly limit object depth;
again, I don't see that concern from other participants, though I
believe your point has been understood. But you claim something slightly
different in your next paragraph:
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.
This is not so much a security risk issue as much as an interoperability
issue: You are claiming here that "the cryptographic canonicalization is
shattered" (unnecessarily dramatic language), which will simply mean
that the signature check will fail and (potentially) the message will
not be delivered. And while that is certainly a potential, (a) you have
not made the case that any other encoding of recipes is better in this
regard (if you have a proposal, please make it), and (b) this question
does come down to running code by way of interoperability experience,
and to quote RFC 2026 section 4.1.1, "neither implementation nor
operational experience is required for the designation of a
specification as a Proposed Standard", which is the target level for
this document. My belief is that the WG understands the risk you have
explained and does not consider it significant enough to prevent moving
forward. I understand that you disagree.
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?
First, DKIM1 did not require any similar complexity because it had no
concept similar to recipes. Second, this is irrelevant bordering on a
logical fallacy: Just because DKIM has been operating without JSON (or
any such complex encoding) does not imply that these new capabilities
can or should do so as well.
- 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.
That's not what I asked for.
The wire format specification itself needs to
enforce strict boundaries.
Please provide text to add to the current document that has such a
restriction that would satisfy your concern. The WG can decide whether
your proposed text is useful or not.
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.
The current document already says:
The value is expressed as an unsigned integer in decimal
ASCII. This value is not constrained to fit into a 31- or 32-bit
integer.
Implementations SHOULD be prepared to handle values up to at least
10^12 (until approximately AD 200,000; this fits into 40 bits).
If you think that is not sufficient, please provide text to supplement
or replace it.
- 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.
Understood. Thanks for the explanation.
- 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.
Architectural discussions are fine. Larger process questions are what I
think are not appropriate for the list.
Did you forget the fundamental rules the IETF was built on: "We
believe in Rough Consensus and Running Code."?
I refer you to RFC 7282.
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.
I again refer you to RFC 2026 section 4.1.1. Running code is not
required at this point in the process.
However, unlike many IETF WGs, there is significant running code in this
case. Running code does not mean perfect code (as if there is such a
thing).
But importantly, rough consensus is a decision criteria for agreeing to
engineering principles. Those engineering principles include weighing
different (often imperfect) options and deciding how to move forward. I
believe that the WG is making such an evaluation.
- 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].
I made no such argument. You asked how, as editor of 5322, how I could
support complex objects in header fields. I only said that by way of
explaining why the former does not impact my view of the latter.
We
should minimize parsing complexity at the trust boundaries, not
compound it. You SHOULD consider consulting John Klensin.
I talk to John quite often.
- 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.
Please give an actual citation to the message, not a characterization of
what he said.
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.
Again, I don't remember Bron saying anything of the sort. Please give an
actual citation to the message.
Operators in the real world require deterministic security, not
administrative consensus.
That is a nice general statement, but I don't see how it applies to this
discussion.
pr
--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
