[Ietf-dkim] Re: New I-D: A Deployment Profile for DKIM2 via Milter Interface

[Vittorio <[e-mail]>]

Richard,
We are going in circles.
Your attack scenario assumes a node that does not verify the previous 
signature, which violates the core requirement of hop-by-hop 
verification in DKIM2-core. Under correct protocol operation the 
mismatch is detected and the message is rejected before it propagates.
You also argue that body recipes help identify a collusive node. But the 
chain of custody already identifies which domain changed the body hash 
without requiring reconstruction, without JSON, without state. That is 
attribution. Reconstruction is a separate property with a separate cost. 
The -02 draft documents this separation in detail.

Regards
Vittorio

Il 2026-04-18 15:30 Richard Clayton ha scritto:
> In message <[e-mail]>, Vittorio
> <[e-mail]> writes
> 
>>> The point of my example was to explain how, when bad people operate a
>>> protocol and do not do what they are supposed then good people can 
>>> draw
>>> incorrect conclusions about what has happened
>>> In particular my example showed how your proposal for verification 
>>> drew
>>> completely the wrong set of inferences as to what has happened:
>>> E concludes that C and D are bad and B is good -- whereas B is the 
>>> only
>>> entity to have altered the body, C and D did not change the body but 
>>> E
>>> incorrectly concludes that they did.
>> Bob changes the body, signs with the old bh= and downstream honest 
>> nodes
>> get blamed. But the scenario only works if the next honest node does 
>> not
>> verify Bob's signature against the body it receives. If Charlie
>> implements DKIM2 (Core) and verifies hop-by-hop, he detects the bh=
>> mismatch at Bob's signature and rejects.
> 
> yes of course
> 
>> If Charlie is a legacy node
>> that does not verify, the gap exists equally whether body recipes are
>> present or not, a legacy node will not generate recipes either.
> 
> you have changed the topic again ...
> 
> ... but in general if a "legacy node" does not change the body and does
> not add any header fields apart from Received (or perhaps some ARC or
> DKIM1 signatures) then the issue will be whether or not it has changed
> the RFC5321 parameters. Hence, one of those old-fashioned "backup MXs"
> that accepts email and forwards it when the main server comes back
> online is very likely to do nothing relevant in DKIM2 terms and so it
> will not matter that it does not understand DKIM2.
> 
> Large mailbox providers run various delay and forward systems inside
> their networks to deal with variations in load. These would also be
> "invisible" so far as DKIM2 receivers thereafter were concerned
> 
>> The remaining case is that Charlie is collusive. But a collusive node
>> can forge recipes just as easily as it can forge bh= values.
> 
> yes they can .. but it is possible for the ultimate receiver to
> determine the last machine in the chain which did any forgery and they
> can then cross that machine off their Christmas card list (or take any
> other action they deem appropriate going forward)
> 
>> Body
>> recipes do not help when the adversary controls a node in the chain,
> 
> No they do and I have just explained (yet again) why
> 
>> they only help when all nodes are honest and cooperating, which is the
>> same trust assumption you criticise in ARC.
> 
> my criticism of ARC is far wider than that
> 
>>> they will not be -- the devices you are concerned about operate at 
>>> the
>>> start and end of delivery paths
> 
> [we're now on the "null recipe" topic]
> 
>> In practice, the topology is *not* that clean. Enterprise security
>> gateways, DLP systems and antivirus proxies routinely sit between MX 
>> and
>> mailbox, not at the edge.
> 
> they are at "the edge" from the point of view of the wider Internet, 
> the
> clue is in the adjective "Enterprise" -- these devices are within the
> network of the entity receiving email from all and sundry.
> 
> That entity has purchased them and has contracts with the suppliers
> which will provide details of the relevant signing keys which can be
> provided to relevant MTAs with the instruction that they are to be
> unconditionally trusted.
> 
> - --
> richard @ highwayman . com                       "Nothing seems the 
> same
>                           Still you never see the change from day to 
> day
>                                 And no-one notices the customs slip 
> away"
>