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

[Vittorio <[e-mail]>]

Hello John,

thank you for the follow-up. A factual clarification first.
Richard Clayton, co-author of the base DKIM2 specification, wrote on 
this list that "DKIM2-core is AIUI all of DKIM2 except for recipes". 
That is, DKIM2-core is not a variant of ARC - it is the mandatory 
cryptographic foundation of DKIM2 itself.

You argue that because the chain of custody resembles ARC, it is proven 
not to work. However, ARC's primary weakness was the lack of 
cryptographic envelope binding (mf=, rt=). This omission allowed for 
replay attacks that DKIM2-core explicitly prevents. To claim that ARC's 
failure is evidence against DKIM2-core is to assume that envelope 
binding adds no security value - an assumption that would invalidate the 
core premise of the entire DKIM2 working group.

Furthermore, if the chain of custody shared by both drafts is "not 
useful" as you suggest, then the base specification is also fatally 
flawed by design, as recipes alone cannot provide attribution without 
that chain. I doubt the chairs or the authors share that view.
I ask directly: do you believe that DKIM2-core with envelope binding and 
DKIM2-Mod accountability is fundamentally unable to solve the 
mailing-list problem? If so, could you describe a concrete attack or 
failure mode that remains? Section 5.7 of the -01 draft documents why 
this approach is sufficient for current p=reject environments and I am 
happy to refine it if a specific counter-example can be identified.
On GDPR: the privacy concern in Section 6 is not that delivering message 
history to a recipient who was going to receive the message anyway is 
problematic. The concern is that body recipes create structured, 
recoverable representations of previous message versions that travel to 
all downstream recipients and archiving systems, potentially including 
content that intermediaries deliberately chose not to transmit - 
redacted DLP content, removed malicious attachments, URL-rewritten 
links. These are new data objects that did not previously exist, created 
by systems that may not have legal basis to create them under GDPR 
Article 5 data minimization. This is a distinct concern from general 
message history and is addressed in detail in Sections 6.2.1 through 
6.2.9.

The -01 draft, submitted a few days ago, also addresses the handling of 
multiple identical headers and the base64 re-wrapping issue.
https://datatracker.ietf.org/doc/draft-moccia-dkim2-deployment-profile/

Regards
Vittorio Moccia


Il 2026-04-10 19:35 John R. Levine ha scritto:
> On Thu, 26 Mar 2026, Vittorio wrote:
>> I have submitted an Internet-Draft formalizing the proposal discussed 
>> on this list in March 2026:
>> draft-moccia-dkim2-deployment-profile-00
>> "A Deployment Profile for DKIM2 via Milter Interface"
> 
> I have read through this draft and do not find it useful.
> 
> It is hard to follow, but as best I can tell, it asserts that it's not 
> possible to implement DKIM2 using the familiar milter interface, so it 
> proposes dividing DKIM2 into two parts, a chain of custody that 
> resembles ARC that one can do in a milter, and a second optional part 
> that tracks message modifications that one can't.  It also makes a 
> claim in section 5.7 that the chain of custody addresses the DMARC 
> mailing list problem, and assertions about European privacy law and the 
> GDPR in section 6.
> 
> We have heard from other people, including people with a lot of 
> experience writing milters, that they see no problem implementing DKIM2 
> in a milter. Hence the fundamental assumption here is wrong.
> 
> Section 5.7 says that mailing lists can look at the chain of custody to 
> decide whether to accept messages without needing the verifiable 
> modification history.  But that was exactly what ARC was supposed to do 
> and we know from extensive experience that it doesn't work.
> 
> Section 6 refers to the GDPR.  As I understand it, the claim is that 
> delivering more details of the history of a message to the recipient 
> who was going to get the message anyway introduces privacy problems.  
> While this seems rather implausible I do not claim to be a European 
> privacy law expert.  None of us are, and if anyone thinks DKIM2 (or any 
> other IETF spec) presents legal issues, they need to talk to their own 
> lawyers.
> 
> R's,
> John
>