On Monday, October 26, 2015 06:47:33 AM Roland Turner via dmarc-discuss wrote: > Scott Kitterman wrote: > > On October 23, 2015 1:48:13 AM EDT, Roland Turner via dmarc-discuss <dmarc-discuss@dmarc.org> wrote: > >>The question is not who you trust - ARC doesn't directly change that - > >>but how you reliably automate determining whether the message was > >>forwarded only by people that you trust. At present, you have to dig > >>through Received: headers, infer per-forwarder internal structure and > >>behaviour and, frequently, guess. ARC addresses that problem, not the > >>one you're asking about. > >> > > I don't see why the signing domain of the DKIM signature that could be > > added by the most recent sender doesn't already give an identifier to use > > to evaluate trust in the sender. > > It does, but that only allows you to identify - and apply your trust > assessment to - the most recent sender. ARC provides a means to > automatically assess the chain *upstream* of the most recent sender.
Only if you already have a high degree of trust in the most recent sender. > It might be worth pointing out that trust is this context is not absolute, > and should not be transitive, because: > > - trusting the integrity (good intention) of the forwarder is not the same > as trusting the competence of the forwarder, and > > - there are different competences that you may or may not be willing to > trust (ability of a forwarder to ARC/DKIM sign correctly and maintain > secrecy of keys is a *far* lower bar than ability of a forwarder to make > exactly the same decisions about what abuse to exclude as those that you as > receiver would make, particularly when you make local, secret decisions as > part of doing so; this distinction gets increasingly acute as receivers get > larger). Since the most recent sender can claim in an ARC stamp whatever arbitrary upstream senders they care to, it seems to me that placing any value at all on an ARC stamp from anything other than a highly trusted sender opens an abuse vector. > > I can see that ARC gives a way to communicate information about > > the upstream senders, but I don't see how that's related to DMARC. > > Many receivers implementing DMARC wish to be able to make decisions about > when to ignore p=reject on a more fine-grained basis than all-or-nothing > trust of the most recent sender. ARC is built to facilitate this and, > therefore, is directly relevant to DMARC. It would already require a high level of trust in the most recent sender not to engage in ARC stamp forgery to do this. Since DMARC is about authentication of an identity (5322.From), if you trust the most recent sender not to have forged the ARC stamp, I'm still not seeing the value of them adding the stamp. > > From a DMARC perspective, if you know the sender is trustworthy, you do a > > local override. ARC doesn't seem to be needed for that. > > You keep talking about "the sender" as if there were only one. In your > message to which I am replying, there are 7 Received: headers in various > formats from 3, 4 or 5 ADMDs, interspersed with various information about > authentication assessments. This is tough for me to assess as a human with > considerable expertise in this area. For software to do it reliably would > be both difficult and fragile. If you don't get why being able to perform > this assessment automatically and reliably is valuable then ARC is never > going to make sense to you, no matter how many detail questions you ask. > I'd suggest that this may simply mean that ARC is not relevant to you and > that, therefore, it may be the case that you can safely ignore it while > those for whom the problem is relevant move forward to run the experiment. When I'm receiving a message, I'm receiving it from a single sender. The message may have a history before that, but from my perspective, it's only got one at the moment. I've never said ARC doesn't have value. I've said I didn't see the value for solving the the issue that DMARC has with mailing lists that perform transformations that break DKIM signatures (like this one). This is the DMARC list, not the ARC list. I'm trying to understand why people seem to be claiming ARC is somehow helpful to DMARC. I don't dispute it may be independently useful, but those uses would be off topic here. > >>The amount of discussion to date about specific historical whitelist > >>proposals is neither here nor there. The question is whether ARC's > >>degree of support for reliable automatic chain-of-custody assessment > >>provides a material improvement for a group of receivers interoperating > >>with a group of forwarders. So long as the answer to that question is > >>yes, then this is progress. I'd suggest that: > >> > >>* large receivers are generally keen to implement things that > >>materially improve their ability to separate wheat from chaff (ARC does > >>this if it's implemented by any significant subset of mailing-list > >>operators), and > >>* at least some of the mailing-list operators whose discomfort with > >>DMARC interoperation is the need to disrupt long-traditional norms > >>(leaving From: unchanged but tagging Subject:, stripping multiparts, > >>adding footers, ...) will be willing to perform ARC processing on > >>messages on the way in, in order to interoperate without giving up > >>traditional mailing-list operations. > >> > >>If these are both true, then ARC is a clear benefit. > >> > > Only if ARC processing materially affects if receivers are willing to > > consider the mailing list as trusted. > > No, as with *ALL* protocol specifications, decisions about who to trust are > out of scope. Operators will always make their own decisions about who to > trust, protocol specifications can't usefully take over this function. The reverse is not true, however. Operation of protocol specifications can give information about who not to trust. By design, DMARC receivers don't trust DMARC fail messages from p=reject domains. ARC doesn't, on it's own, seem to provide any change in that regard. > > ARC appears to leverage knowledge of who are trusted senders > > to make it easier to trace a message path. > > Yes. > > > If there's a way to know which senders are trusted, then > > DMARC can already be overridden. > > No, for the reasons outlined above, it's not currently possible - in general > - to work out whether the sender named in a particular Received: header > actually handled the message. Your argument is a little like claiming that > DKIM is not necessary because if you trust the domain named in the From: > header and also the most recent sender then you don't need to perform your > own signature validation. The need for DKIM arises specifically because > this is not true, even for forwarding that does not modify messages. ARC > addresses an analogous problem for forwarding which does modify messages. No. That's not right either. Without something like SPF or DKIM you've got no authenticated identifier to leverage. It's not analogous though. As a domain owner, I can control what sources of mail are able to generate mail that passes SPF or has a valid DKIM signature with d= my domain. Anyone, anywhere can generate an ARC stamp with my domain in it, so it's completely different. > > Maybe I am just failing to understand, but this reads to me > > like a solution to the DMARC mailing list problem that only > > works if there already exists another solution to the DMARC > > mailing list problem. That or it's completely unrelated to DMARC. > > I'm not sure which. > > The fact that chain-of-custody doesn't immediately jump out at you as an > extremely useful tool for receivers suggests that you've never needed to > solve the problem in question. The issue then is simply that the problem is > not relevant to you personally, in which case perhaps the solution isn't > either. Please stop claiming I said ARC is not useful. I didn't. If I was arguing that, I'd have subscribed to the ARC list and argued it there. On this list what I'm looking for is relevance to DMARC and the issues DMARC currently has. I think you've pretty much confirmed ARC and DMARC are orthogonal technologies that address different issues. That's fine. Scott K _______________________________________________ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
