... stays at M3AAWG they say. But I have some notes from in-person discussions to bring to the list.
The main thrust of the discussion was "what does ARC currently provide which would be lost in the transition to DKIM2" - with an eye to "can we retain this capability, so nobody sticks with ARC". There are two things here: *One** - the SPF bootstrap problem* There's still plenty of mail which is only SPF aligned on the first hop, which ARC explicitly calls out as an acceptable thing, the first AAR header says "spf=pass" and everybody is happy. We figured that if your SPF is all just IP ranges, then there's nothing that could be done, BUT if your SPF has an `include:spf.sendersystem.com` then we could allow the first hop to be signed by either the domain `spf.sendersystem.com` or an explicit subdomain, e.g. mail from [email protected] could be signed by `example.com.spf.sendersystem.com`. The exact details of the bikeshed need to be hashed out. This could either be purely the fact of the include, or it could be an SPF extension (in the same or another record) which was DKIM2SPF or whatever, some kind of "it's permitted to send from this domain with DKIM2-Signature signed by whoever the SPF record says", and then leverage the `include:` rules' indirection to allow sendersystem.com to set up DKIM2 automatically for those emails. *Two - the trusted modifier problem* Right now ARC requires you to trust systems that modify stuff, and so you have to keep a list of "it's OK if this domain modifies stuff". You can tell that they did because the ARC-Signature's hash changes between hops. DKIM2 does the same thing on steroids, not only does the Message-Instance hash change, but there's a recipe describing how to undo the change. Unless the recipe doesn't allow you do undo the change, then you still need to trust the signer. There will be some sites which do this, and everyone downstream will have to trust them to have: 1. verified DKIM2 correctly on the way in, 2. only made "trustworthy" modifications, whatever that means, and most trickily 3. verified that the content they left unchanged is unlikely to be considered "bad" by anyone afterwards, since it won't be possible to validate where it was injected if two different parties both make irreversible changes. Right now, DKIM2 encourages diverse signing domains. A big infrastructure with millions of domains will use the key for each domain to sign email that is transiting for that domain. customer1's email will be signed by a `d=customer1.com` key, and customer2's with a `d=customer2.org` key. If the same infrastructure makes irreversible modifications to all those messages, then everyone will have to individually trust every one of those keys. If instead, the irreversible Message-Instance header was signed by `d=modifyingsystem.com` then we'd only have to trust that. There are a few ways to get there: 1. synthetic mf= and rt= sequence 2. re-use the `include:` syntax above to bridge discontinuities in the chain 3. allow interstitial Message-Instances to be signed without an mf=/rt= pair. In the case where I have [email protected] <mailto:[email protected]> forward to [email protected] (it actually does that, I just created it), supposing that Fastmail modiified the message irreversibly, and wanted to sign with domain `d=messagingengine.com` (which we actually do with DKIM on outbound messages now, along with the individual domain), then each case would look like this on arrival 1) synthetic mf= and rt= DKIM2-Signature: i=3; v=2; d=messaginengine.com; [email protected]; [email protected] Message-Instance: 2; [...] (irreversible damage done here) DKIM2-Signature: i=2; v=1; d=brong.net; [email protected]; [email protected] DKIM2-Signature: i=1; v=1; d=icloud.com; [email protected]; [email protected] Message-Instance: 1; [...] (just hashes) From: [email protected] To: [email protected] 2) re-using the include syntax: ;; ANSWER SECTION: brong.net. 3600 IN TXT "v=spf1 include:spf.messagingengine.com ?all" DKIM2-Signature: i=2; v=2; d=spf.messaginengine.com; [email protected] <mailto:[email protected]>; [email protected] Message-Instance: 2; [...] (irreversible damage done here) DKIM2-Signature: i=1; v=1; d=icloud.com; [email protected]; [email protected] Message-Instance: 1; [...] (just hashes) From: [email protected] To: [email protected] 3) allow Interstitial Message-Instances to be signed without otherwise being included in the flow. DKIM2-Signature: i=3; v=2; d=brong.net; [email protected]; [email protected] DKIM2-Signature: i=2; v=2; d=messagingengine.com Message-Instance: 2; [...] (irreversible damage done here) DKIM2-Signature: i=1; v=1; d=icloud.com; [email protected]; [email protected] Message-Instance: 1; [...] (just hashes) From: [email protected] To: [email protected] (it's clear from the order that the first signature on the breaking Message-Instance is messagingengine.com) 4) A combo of include syntax and synthetic mf=/rt= which allows us to get avoid having to sign with brong.net at any point, while still having the exact `messagingengine.com` domain do the mangling, and also with a To: rewrite on the final hop. DKIM2-Signature: i=4; v=3; d=messagingengine.com; [email protected]; [email protected] Message-Instance: 3; [...] { "rh" : { "To" : ["[email protected]"] } } DKIM2-Signature: i=3; v=2; d=messagingengine.com; Message-Instance: 2; [...] (irreversible damage done here) DKIM2-Signature: i=2; v=1; d=brong.net.spf.messagingengine.com; [email protected]; [email protected] DKIM2-Signature: i=1; v=1; d=icloud.com; [email protected]; [email protected] Message-Instance: 1; [...] (just hashes) From: [email protected] To: [email protected] Hopefully these examples are easy to enough to read and understand! I look forward to more discussion of whether the SPF include syntax based linkage is necessary and/or desirable, both for initial SPF and for later forwarding-permitted-for or whatever we might consider it; to parallel the DKIM->DKIM2 meaning of the key going from sending-as to sending-or-forwarding-as. Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
