I thought long and hard about using a less inflammatory title, but I figure maybe going in hard is the right way here, because I'd rather fix this before it becomes a standard! (and thanks Dave for your thoughtful questions during the Prague DMARC session which prompted some of my thinking) Unfortunately I didn't get a full chance to think about ARC and how it all functions before Prague, and then I hadn't fully internalised it by the DMARC session - I was still refactoring the code I wrote on the weekend and testing it some more, as well as getting the signing side done. It took a few days to fully understand how all those signatures work together. I had let others focus on ARC within our company rather than looking at it myself until now. So my apologies for coming along late with this manifesto! I've been trying to think of a more polite and diplomatic way to say it, but so far I haven't see anything to convince me that ARC-Seal is anything other than snake oil. It's excessive crypto for no benefit, and with the way I've had it described to me and the way it's being used right now at least at Google (sealing every message on the way in), it adds confusion rather than clarity to message provenance. Let me explain. Starting with purpose.
ARC conflates two purposes: a) providing a new signature when you change a message in ways that break its existing signature. b) providing a signature where there is none, but SPF passed and you would have trusted the source email anyway. Apparently "just DKIM sign everything" isn't viable due to key management problems and "sending on behalf of". I'm willing to stipulate that, because we have to work with the reality of deployed systems with any new standard if it wants traction. There is a third purpose that needs signatures: c) new email received from trusted/internal host with no signature yet This is generally handled by DKIM-signing the message before sending it outside an organisation's trusted infrastructure. FastMail for example DKIM signs our outbound email during the final scan before adding to the outbound queues. Internally it travels around with an internal-only header that identifies the sending user to allow us to choose which DKIM signatures to apply, then we sign on final injection into the outbound queue. I suspect other organisations do the same, and this is what DKIM was designed for. My understanding of ARC is that is not supposed to replace DKIM for this case. Anyway, we are conflating: 1) I need to sign this email which I didn't modify because the next hop wouldn't be able to verify that it was sent from an authorised source any more; with 2) I'm modifying this message and I am asserting that I believed it was from an authorised source and correctly signed before I modified it Right now AAR and AMS are exactly the same for those two cases. The problem is - advice on "when should I ARC-Seal" is really woolly, leading to a third case being conflated in here: 3) I'm not modifying this message or breaking its signature, I'm just adding my own signature as it passes through Case three is the real problem. By adding an AAR, AMS and AS in that case, you're adding crypto which is misleading. I will make my case below :) I use the following parties: d=gmail.com - a sender and eventual receiver. I could sub fastmail.com here just as easily, but "everyone" knows gmail, and they currently ARC- Seal all incoming email. d=mailinglist.com - a mailing list which modifies all email, and hence needs to apply ARC to every message for case (2) above. d=forwarder.com - a site that just forwards email without changing the message at all - something like pobox.com, our alias service. d=sketchy.com - another forwarder who isn't well known or trusted. Trust isn't transitive, gmail trusts mailinglist.com to validate signatures and to only apply clean transformations (change sender, add a footer) to any email it receives, but it doesn't trust sketchy.com at all. mailinglist.com on the other hand isn't sure about sketchy.com, but has no reason to consider it less trustworthy than other forwarders because it doesn't have a giant machine learning database to handle site reputation. Now let's consider the following message history. The mail is going to follow this path: gmail.com => sketchy.com => mailinglist.com => forwarder.com => gmail.com This seems somewhat contrived, but maybe sketchy.com is some university system where a club has set up an alias that goes to their mailing list, and one of the members is an alumnus using a separate university alumni system which forwards to their gmail account. That's not a totally unreasonable mail flow. Here's a message where sketchy.com just forwards the message, with no changes made: original message: DKIM-Signature: d=gmail.com (VALID) From: <f...@gmail.com> To: <list-n...@sketchy.com> first hop: AS: i=1, d=sketchy.com, cv=none (VALID) AMS: i=1, d=sketchy.com (VALID) AAR: i=1, dkim=pass, spf=pass, arc=none DKIM-Signature: d=gmail.com (VALID) From: <f...@gmail.com> To: <list-n...@sketchy.com> ENV-To: <n...@mailinglist.com> second hop: AS: i=2, d=mailinglist.com, cv=pass (VALID) AMS: i=2, d=mailinglist.com (VALID) AAR: i=2, dkim=pass, spf=fail, arc=pass AS: i=1, d=sketchy.com, cv=none (VALID) AMS: i=1, d=sketchy.com (INVALID) AAR: i=1, dkim=pass, spf=pass DKIM-Signature: d=gmail.com (INVALID) From: <n...@mailinglist.com> To: <al...@forwarder.com> We see that both DKIM and i=1 AMS are now invalid, only the AS chain continues to validate. The DKIM still passed on arrival to mailinglist.com, because sketchy.com didn't actually modify the message, but won't pass again after this. third hop: AS: i=3, d=forwarder.com, cv=pass (VALID) AMS: i=3, d=forwarder.com (VALID) AAR: i=3, dkim=fail, spf=fail, arc=pass AS: i=2, d=mailinglist.com, cv=pass (VALID) AMS: i=2, d=mailinglist.com (VALID) AAR: i=2, dkim=pass, spf=fail, arc=pass AS: i=1, d=sketchy.com, cv=none (VALID) AMS: i=1, d=sketchy.com (INVALID) AAR: i=1, dkim=pass, spf=pass DKIM-Signature: d=gmail.com (INVALID) From: <n...@mailinglist.com> To: <al...@forwarder.com> ENV-To: <b...@gmail.com> and finally gmail seal it on the way in: AS: i=4, d=gmail.com, cv=pass (VALID) AMS: i=4, d=gmail.com (VALID) AAR: i=4, dkim=fail, spf=fail, arc=pass AS: i=3, d=forwarder.com, cv=pass (VALID) AMS: i=3, d=forwarder.com (VALID) AAR: i=3, dkim=fail, spf=fail, arc=pass AS: i=2, d=mailinglist.com, cv=pass (VALID) AMS: i=2, d=mailinglist.com (VALID) AAR: i=2, dkim=pass, spf=fail, arc=pass AS: i=1, d=sketchy.com, cv=none (VALID) AMS: i=1, d=sketchy.com (INVALID) AAR: i=1, dkim=pass, spf=pass DKIM-Signature: d=gmail.com (INVALID) From: <n...@mailinglist.com> To: <al...@forwarder.com> ENV-To: <b...@gmail.com> In here we have two things that are interesting: 1) the oldest AMS that still validates. Nothing was changed since then.2) the AAR with the same i= value (i=2) which shows that DKIM still passed then. So we can tell from these headers that the only place which modified the message was mailinglist.com. So far so good. Absent ANY value at all are the ARC headers with i=1, i=3 or i=4. They add no value. Likewise the ARC-Seal at i=2 only adds value because it signs the AAR at i=2. This is literally the only proof we have at this point that sketchy.com didn't completely rewrite the message. This same value could be obtained by having sketchy.com and forwarder.com and gmail's inbound do no ARC processing at all other than validating the AMS of mailinglist.com rather than the DKIM signature at forwarder.com and gmail.com inbound. The only way to know that sketchy.com didn't modify the message is because mailinglist.com's AAR said that dkim still passed at that time. But mailinglist.com could easily lie about that if it wanted to, the chain would still be unbroken. Further, ARC-Seal doesn't capture the really interesting bits - which are "what was the envelope at this point" or even "what was the date at this point" - meaning you can re-purpose old ARC-Seals for as long as you like if the selectors still exist, and they will continue to validate. OK, this has become pretty long and rambly, but here's the thing: *AS adds nothing over just having AMS signing its own AAR, and then you only have to verify ONE signature, the most recent.* Any site which lies about AAR and also modifies the message can just as easily file the serial numbers off an existing ARC chain, pretend it received the message from a point in that chain, and then mint a convincing AAR, a valid AMS and a valid AS which chains with the existing set of seals. The seals don't include any previous facts about the message other than the hashes in the lower i= AMS headers, and a single modification to message content will render them invalid. Short of a global registry of all known email mesages (in which case ARC is pointless), you can't tell if those ARC headers were lifted off another message and reused. You either trust the most recent signer and trust that THEY validated the previous signer/SPF (and so on) or the chain is broken anyway, so why add a parallel, easily falsified, chain of signatures? So since ARC-Seal doesn't add any value, and adds complexity and cost (in extra DNS lookups and crypto) and failure points (in potential DNS tempfails which break the chain even though the underlying crypto is sound and could be verified later) - it's a waste and, as I stated in the subject, snakeoil with no benefit. What is valuable is AMS and AAR, and along with that - advice to not add your own AMS unless you really have to. If you aren't breaking the existing signature, don't add your own, because it confuses provenance on the message. ARC would be a better standard if it removed AS entirely, and had AMS sign its own AAR (e.g. by adding another tag to the AMS header which is the hash of the associated AAR) A more cheap and nasty fix, assuming it's too late/complex to change the protocol more, would be to keep AS, but change the validation to only require checking the most recent AS, since validating the rest is meaningless. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd br...@fastmailteam.com
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
