Using the earlier definitions/assumptions, I wanted to further clarify the claimed replay security properties. To recap, we do the following checks with DKIM2-REPLAY:
- DKIM2 rt= address matches RCPT TO and mf= address matches MAIL FROM. - A given DKIM2 i=n signature mf= address matches the immediate earlier DKIM2 i=n-1 rt= address. - In addition this approach claims there must be alignment with the sender's rt= domain with the d= domain, with the sender's mf= and d= domain. To start, let's consider a direct send. DKIM2 Originator → DKIM2 Receiver originator: DKIM2-Signature: i=1; d=originator.example; [email protected]; [email protected] DKIM-Signature: d=originator.example Receiver sees: MAIL FROM: <[email protected]> RCPT TO: <[email protected]> DATA DKIM2-Signature: i=1; d=originator.example; [email protected]; [email protected] From: <[email protected]> Receiver can check that rt= and mf= content against RCPT TO and MAIL FROM to check for replay. It also can check that the sender's DKIM2-Signature d= domain matches the mf= domain, and that the mf= matches the prior DKIM2-Signature rt= if present. DKIM2-REPLAY reports pass. Then let's consider three replay attack scenarios and see how DKIM2-REPLAY will not pass. This assumes that the message signature check passes. For the first one, let's take the above delivered message and replay it by directly sending to a DKIM2 victim receiver. Spammer → DKIM2 victim Victim sees: MAIL FROM: <[email protected]> RCPT TO: <[email protected]> DATA DKIM2-Signature: i=1; d=originator.example; [email protected]; [email protected] From: <[email protected]> Here you can see the rt= address mismatches the RCPT TO which will lead to DKIM2-REPLAY neutral. For the second one, let's take the above delivered message and the spammer is DKIM2 aware. The spammer DKIM2 signs it as themselves including the mf= and sends the updated message to a DKIM2 victim receiver. DKIM2 Spammer → DKIM2 victim Victim sees: MAIL FROM: <[email protected]> RCPT TO: <[email protected]> DATA DKIM2-Signature: i=2; d=spammer.example; [email protected]; [email protected] DKIM2-Signature: i=1; d=originator.example; [email protected]; [email protected] From: <[email protected]> We can see that the address in i=1 rt= and i=2 mf= mismatches which will lead to DKIM2-REPLAY neutral For the third one, let's take the above delivered message and the spammer is DKIM2 aware. The spammer DKIM2 signs it as themselves but spoofs the mf= and sends the updated message to a DKIM2 victim receiver. Victim sees: MAIL FROM: <[email protected]> RCPT TO: <[email protected]> DATA DKIM2-Signature: i=2; d=spammer.example; [email protected]; [email protected] DKIM2-Signature: i=1; d=originator.example; [email protected]; [email protected] From: <[email protected]> We can see that, while the that the address in i=1 rt= and i=2 mf= matches, the second DKIM2-Signature i=2 d= domain mismatches the mf= domain which in this proposal will lead to DKIM2-REPLAY neutral. On Wed, Sep 17, 2025 at 9:26 AM Wei Chuang <[email protected]> wrote: > First I wanted to propose adopting draft-clayton-dkim2-spec > <https://datatracker.ietf.org/doc/draft-clayton-dkim2-spec/> as a DKIM > working group document for the specification of DKIM2. I think it is a good > starting point for defining the DKIM2 signatures. > > Second, interop is an area that needs much more discussion by the working > group. I think we all agree that adopting DKIM2 will be a lengthy process > where it has to work with an ecosystem with widespread DKIM1 deployment. > This writeup considers one approach for DKIM2 to interoperate with DKIM1 > where the goal is to add DKIM2 where possible even if the message did not > originate or was not forwarded from a DKIM2 aware sender. When this is > done, this considers how to evaluate those results in a safe way and how > this improves upon the current situation with authentication i.e. improves > upon DKIM1. > > Some assumptions that I make are: > > - > > Per RFC5598, there are originators, receivers and forwarders which > relays that are neither associated with originators or receivers. > - > > DKIM1 aware originators add a DKIM signature. > - > > Some DKIM1 forwarders may also add a signature especially if it wishes > to take "ownership" of the message i.e. rewrite payload From header field > to support DMARC. > - > > DKIM2 aware originators and forwarders add DKIM2 > <https://datatracker.ietf.org/doc/draft-clayton-dkim2-spec/> > signatures. To be compatible with DKIM1, they will also add the DKIM1 > signature as above including "ownership" changes. > - > > DKIM2 body and header algebra can undo forwarder's modifications > including any "ownership" changes as specified in > dkim2-modification-alegbra-02 > > <https://datatracker.ietf.org/doc/html/draft-gondwana-dkim2-modification-alegbra-02> > . > > Also from draft-clayton-dkim2-spec > <https://datatracker.ietf.org/doc/draft-clayton-dkim2-spec/> section 5.2 > > - > > DKIM2 rt= address matches RCPT TO and mf= address matches MAIL FROM. > A given DKIM2 i=n signature mf= address matches the immediate earlier DKIM2 > i=n-1 rt= address. > > > This proposal changes draft-clayton-dkim2-spec > <https://datatracker.ietf.org/doc/draft-clayton-dkim2-spec/> in the > following ways. > > - > > DKIM2 domain alignment with the sender's rt= domain with the > receiver's DKIM2 d= domain, with the sender's mf= and d= domain. Tying the > envelope address domains to DKIM2 signer enables independent verification > that the message got to the right place. > - > > Add to the f= flags a new value "origination" that describes when > DKIM2 is added at origination. > - > > Separate out verification into a weaker but more general test around > signatures, and a stronger more precise result that adds the address > matching . > - > > DKIM2-SIGNATURE verification uses Section 6.1.3 to determine if all > the modifications are explainable. Compute the Verification for the > current i=n. If PASS continues as described next, else report NEUTRAL > and > stop. Apply algebra to reverse changes. Repeat for i=n-1 until i=1. > - > > DKIM2-REPLAY verification checks addresses as called on in Section > 5.2 to help detect and prevent replay. It matches the envelope MAIL > FROM > and RCPT TO against the DKIM2- mf= and rt= addresses. Check that i=n > mf= > address matches i=n-1 rt= address. As mentioned check the > DKIM2-SIGNATURE > concurrently. If any of these fail, report NEUTRAL. Repeat the check at > i=n-1. i=1, f= must also contain "origination". If so, report PASS. > > > This proposes modifying DKIM1 > <https://www.rfc-editor.org/rfc/rfc6376.html> to make use of algebra to > reverse the changes. > > - > > DKIM1-SIGNATURE starts at i=n. If DKIM2-SIGNATURE passes then attempt > to verify DKIM1 signatures. Report passes Apply algebra to reverse > changes. Repeat the check at i=n-1. Passing DKIM2-SIGNATURE protects the > integrity of the algebra headers. > > Scenarios > This enumerates various abstract email delivery scenarios primitives. > Other scenarios may be reduced to these though of course there are others > that cannot. For a more detailed description of scenarios see RFC5598, and > draft-robinson-dkim2-message-examples > <https://datatracker.ietf.org/doc/draft-robinson-dkim2-message-examples/>, > > Direct send is the common case. > > 1. DKIM2 Originator → DKIM2 Receiver > > The DKIM2 aware receiver uses the originator's DKIM2 headers to verify the > DKIM2-REPLAY result. Such a result indicates that the message was not > replayed nor modified during transit. > > 2. DKIM1 Originator → DKIM1 Receiver > > The DKIM2 aware receiver uses the originator's DKIM1 headers to verify the > message using the RFC6376 algorithm with the existing limitations around > replay. > > 3. DKIM1 Originator → DKIM2 Receiver > > The DKIM2 aware receiver uses the originator's DKIM1 headers to verify the > message using RFC6376. No attempt is made to verify DKIM2-SIGNATURE or > DKIM2-REPLAY as the DKIM2 headers are not present. > > 4. DKIM2 Originator → DKIM1 Receiver > > The DKIM1 aware receiver uses the originator's DKIM1 headers to verify the > message using RFC6376. > > Forwarding is less frequent than direct sending, but much more problematic > due to replay and forwarder modification of the message. Here the > forwarder is a mailing list that adds a footer, and modifies the Subject > header field to describe the changes the mailing list did. To prevent the > modification from causing DMARC verification failure, it takes ownership of > the message by DKIM1 re-signing the message and modifies From header to > align with the new DKIM1 signature. > > 5. DKIM2 Originator → DKIM2 Forwarder → DKIM2 Receiver > > The DKIM2 Originator signs the message with a DKIM2 signature. DKIM2 > Forwarder is a mailing list that modifies the message. It reports the > changes as DKIM2 algebra and signature, and takes ownership as described > above. The DKIM2 Receiver applies the DKIM2-REPLAY algorithm to use DKIM2 > algebra to reverse the change, and recover the original message. Such a > result indicates that the message was not replayed nor modified during > transit. > > 6. DKIM1 Originator → DKIM2 Forwarder → DKIM2 Receiver > > The DKIM1 Originator signs the message with a DKIM1 signature. DKIM2 > Forwarder is a mailing list that modifies the message and takes ownership. > It reports the changes as DKIM2 algebra and signature, and takes ownership > as described above. The DKIM2 Receiver applies the DKIM1-SIGNATURE > algorithm to use DKIM2 algebra to reverse the change, and recover the > original and forwarder's passing DKIM1 signature. This can be reported as > a RFC6376 PASS with the originators signature. When verification is > attempted with DKIM2-SIGNATURE or DKIM2-REPLAY, these will return a > NEUTRAL. > > 7. DKIM2 Originator → DKIM1 Forwarder → DKIM2 Receiver > > The DKIM2 Originator signs the message with a DKIM2 signature. DKIM1 > Forwarder mailing list that modifies the message and takes ownership. The > DKIM2 aware receiver sees the DKIM2 headers and attempts to verify > DKIM2-SIGNATURE, DKIM2-REPLAY and DKIM1-SIGNATURE, but these will return a > NEUTRAL. When it verifies RFC6376, it will see a pass on the forwarder's > DKIM1 signature. > > 8. DKIM1 Originator → DKIM1 Forwarder → DKIM2 Receiver > > As there are no DKIM2 headers, the DKIM2 aware receiver, uses the > forwarder's DKIM1 headers to verify a PASS using RFC6376 > > 9. DKIM2 Originator → DKIM2 Forwarder → DKIM1 Receiver > > 10. DKIM1 Originator → DKIM2 Forwarder → DKIM1 Receiver > > 11. DKIM2 Originator → DKIM1 Forwarder → DKIM1 Receiver > > 12. DKIM1 Originator → DKIM1 Forwarder → DKIM1 Receiver > > The DKIM1 aware receiver uses the forwarder's DKIM1 headers to verify a > PASS using RFC6376. > > As you would expect, this approach provides anti-replay benefits when the > entire path is DKIM2. It also provides some improved authentication that > identifies the originator when the forwarder and receiver are DKIM2. In > other cases the receiver falls back to DKIM1 authentication. > >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
