We have not looked in detail at how the DKIM2 trust model will work with security gateways for forwarded messages. With other security gateway scenarios, we have plausible trust models. For inbound security gateways the receiver that delegates to an inbound security gateway will trust its output including when the security gateway modifies the message. However this is not true when the message is forwarded since there isn't that relationship. For outbound security gateways, when the outbound security gateway modifies the message, it will have to sign on the behalf of the message originator which is possible because it works on behalf of the originator. However the trust model of forwarded messages is different because the forwarder typically does not want to take full ownership of the message originated elsewhere because it may be spam. Such a forwarder might be an alumni forwarder or a retired mailbox for a former user that forwards as a courtesy.
Security gateways may modify the message in complex ways that message algebra cannot cover such as deleting attachments that will then fail DKIM2 validation. One alternative is to take full ownership of the message which is contrary to the desire of the forwarder. This may be a much less desirable possibility such that the forwarder may want to stop this sort of forwarding altogether as they cannot guarantee to prevent sending spam. Another alternative would be to tell them to stop modifying messages though they will note that they are doing this because they have been told to prevent spam and they want to protect their users from phish and malware. Another better alternative IMO is to find a better authentication and trust model for security gateways with forwarders. So what do we want for authentication through security gateways: * Securely identify the originator and forwarders, potentially as DKIM2 signers of DKIM2 signatures * Protect meaning be able to verify integrity of header content * Tolerate fairly complex modifications such as deleting attachments, or wrapping URLs Verify header modifications through header algebra One idea is to ask receivers to fully trust the security gateway as the modifications done are to protect the receiver's users with best effort by the gateway. If so we can build an authentication model that can ignore body modifications with certain requirements as we should minimize the scope of this trust. In the past, I've mentioned that we can separate out the DKIM2 hashes for the header and body to tolerate body changes while letting us recover changes to headers via algebra. Valid headers along DKIM2 signature "chain" validation lets us recover an authenticated delivery trace of the message which can be a useful authentication identifier. The security gateway MUST DKIM2 verify inbound messages. If a message fails validation, it MUST apply the to be defined DKIM2 policy that includes DMARC. Subsequent receivers MUST acknowledge that validation failure at the security gateway may be tolerated according to DMARC sender policy and local policy. Security gateways MUST update the body algebra metadata present in the message to account for any body modification applied at the gateway. A subsequent receiver can verify that a message came from a security gateway without tampering and use the update algebra to discover which contribution came from the originator and prior forwarders. This begs the issue of how do we find this list of trusted security gateways, as any malicious sender would then declare themselves a security gateway. *Allow list of security gateway providers* Create such a list of security gateway providers based on reputation through a vetting process by peers that are experts in the field. There could be some committee under the M3AAWG aegis that could do this. While it risks getting like the M3AAWG ARC trust list process, the difference is that the scope is actually narrower IMO. The M3AAWG ARC trust list committee was tasked with finding out which quite arbitrary forwarder would generate valid ARC-Authentication-Results which itself is based on the forwarders capability for generating DKIM and SPF validation results which is subject to local policy. For DKIM2, we are asking the forwarder the DKIM2 headers unmodified. We also must trust them not to replay the headers. This allowlist would be defined by a list of domains that would be used to sign the DKIM2 signatures. *Certification Process for Security Gateways* Use X.509 certificates to declare trusted security gateways. The CA would issue certificates that declare a set of verifiable security gateway characteristics: * Same verifiable list of M3AAWG expert declared security gateways * Code audit A huge downside is that DKIM likely needs a new assertion publication and validation mechanism as well as to stand up a new PKI. Both are costly but not impossible as BIMI provides most of the outlines of how to do this. See if BIMI drafts if interested, but admittedly it is fairly complex. The main benefit is a much more precise trust relationship in this model between the different parties such as revocation of trust if a party cheats for example. Certification could be useful in other contexts and if more scale is necessary. Also BIMI has been reasonably well adopted so would not be considered a barrier to entry. Further the Certified Sender Alliance has also seen a large amount of adoption. The allow-list mechanism is a much easier starting point, and the certification process only if necessary. This proposal suggests starting with an allow-list mechanism, and revisiting as necessary. Thoughts? Would an example help? -Wei
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
