Scott Kitterman wrote: > On Monday, October 26, 2015 06:47:33 AM Roland Turner via dmarc-discuss wrote: >> Scott Kitterman wrote: >> > 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.
No, see my earlier comments (that you quoted) immediately below. >> 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. Not just the most recent sender, all senders. Yes, you should only trust ARC signatures by senders whose integrity you trust, obviously. >> > 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. You would only see value in them adding the stamp if you assumed that they were not trustworthy? I've re-read your paragraph above three times and really don't understand your argument. I do wonder whether you're confusing trust of integrity with trust of ability to exclude abuse. Care to re-phrase? >> > 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. In the sense that the SMTP connection came from a specific IP address, sure, but that's a little beside the point. Many receivers implementing DMARC care about the trustworthiness of each link in the chain, not merely the last one. > 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 have assumed that it was self-evident that the context was DMARC. > 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. I am only discussing uses in a DMARC context. >> >>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. This is true but not relevant; I raised this particular limit of protocol specifications in rebutting your claim that ARC is beneficial only if it affects receivers willingness to consider a mailing list to be trusted. > ARC doesn't, on it's own, seem to provide any change in that regard. How ARC seems will depend pretty strongly on an element of your worldview: - It appears that you wish to make DMARC p=reject override decisions based solely upon the level of trust that you place in the most recent forwarder. This is your prerogative. For receivers wishing to operate in this mode, ARC clearly provides no benefits, at least not for DMARC purposes. - Others wish to be able to look further upstream. From their perspective ARC provides material benefit in a significant class of unresolved DMARC problems. For this group, ARC appears likely to be a useful enabler for DMARC. > 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. No, they can't. (More accurately, like a DKIM signature, anyone can create one, but it won't validate unless they've also gotten their hands on one of your private keys.) >> > 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. As above, I'd considered it self-evident that we were discussing ARC in a DMARC context. You have repeatedly suggested or asserted that ARC is not useful in a DMARC context. It's becoming reasonably clear that the issue is that you've never had cause to assess upstream information in deciding whether to override a DMARC p=reject failure and, therefore, don't immediately grasp why validatable chain-of-custody information is valuable. That's fine. That it's not valuable to you doesn't mean that it's not valuable to others. > I think you've pretty much confirmed ARC and DMARC are orthogonal technologies > that address different issues. That's fine. Quite the contrary, I've only discussed ARC's use in DMARC. You may safely assume that any claims I make about ARC on this list are, specifically, about ARC's use with DMARC unless I state otherwise. - Roland _______________________________________________ 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)
