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]
