> -----Original Message----- > From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Scott Kitterman > Sent: Tuesday, August 08, 2017 10:28 AM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] ARC-Seal is meaningless security theatre > > On Tuesday, August 08, 2017 11:59:19 PM Bron Gondwana wrote: > > On Tue, 8 Aug 2017, at 23:36, Kurt Andersen (b) wrote: > > > On Mon, Aug 7, 2017 at 9:10 PM, Bron Gondwana > > > <br...@fastmailteam.com> wrote:>> __ > > > > > >> . . . If you aren't willing to agree that the most recent liar can > > >> > > >> repurpose an existing chain, I'm happy to avoid making the forgery, > > >> otherwise I'll make up a forgery and send it to the list.>> > > >> > > >> But since you either trust every hop to do good checks, or you > > >> don't trust the entire message - then the ARC-Seal is literally > > >> adding nothing. It adds no meaning, just extra work. Hence my > > >> snakeoil claim.>> > > > > > > Is your concern that the last hop (or any other) can essentially do > > > a wholesale replacement of the message contents and that there is no > > > way to distinguish that from a semantically meaningless footer > > > tweak?> I'm not sure that I understand your assertion that you can > > > forge an AS any more than you could forge a DKIM signature. > > > > The whole point of verifying the chain of AS all the way back to i=1 > > is that you can tell that the message went through those servers, in > > that order. > > But it's bogus, because AS doesn't sign anything except itself and > > some AMS and AAR. Once AMS doesn't validate any more (any change at > > all) then you can't really tell that the message passed through there, > > just the _a_ message passed through there. > > So I could take an existing message that had passed through Google and > > create a brand new message and pass it off as if it had passed through > > Google before passing through my server on its way to you. > > In which case - the AS is meaningless. It claims something which is > > only true if everyone plays by the rules. But if everyone plays by > > the rules, then it's excessive. You could just check the previous AAR > > and know that the previous site had validated the hop before it, and so on. > > It's crypto that doesn't add anything of value. > > It's not actively damaging (other than the advice to do excessive DNS > > lookups), but it's also not doing anything meaningful, and it's adding > > something forgeable that looks like it means something. > > Bron. > > I think the "Once AMS doesn't validate anymore ..." argument is an > suggestion that it's fragile, not that it's pointless. I have concerns myself > about the robustness of this design, but I think that's best addressed through > deployment and experimentation. > > The fail case isn't very interesting. If it doesn't validate it, ignore it. > > I'm not sure yet what exactly the pass case buys, but I'm not convinced it's > nothing. > > Scott K >
I think the other thing that needs to be remembered is that DMARC, and subsequently ARC, is a request to the mailbox provider/validator. ARC is presumably used as an input for local policy in consideration of overriding DMARC failures. The fact that ARC validation is successful at the mailbox provider is ultimately a matter of local policy and presumably some sort of reputation schema. Mike _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
