John Levine writes: > It appears that Daniel K. <dan...@vendo.no> said: > >I'd rather eliminate any possibility of this type of bad actor to send > >bogus third party reports in the first place, but it seems like that is > >not going to happen. > > How much are you willing to pay every mail system in the world to > make major changes to their reporting system to address this entirely > hypothetical non-problem? That's not how standards work.
And if someone invents a way to use this attack vector to do something bad (even if we have not invented how to use things for attacks does not mean that someone does not do that in the future), how much you want to do pay for us to come back in few years and fix the standard and also all the implementations in short timeframe to stop that attack? I know that security is not high up in the list of things email people do, but I usually work on the security area, and there we must always think about all possible ways of attacking the system, even when nobody has used those attack vectors before. We have to list all ways someone could attack the system and make sure we know what will happen when someone uses that attack vector. If what happens is bad, then we need to provide solution against that attack vector. If those aggregate reports are only "for your information only", and there is no actual actions ever happening based on those reports, then fake reports most likely will not cause any issues. If there is someone somewhere who are using automated tools and perhaps doing some actions based on those reports then they can be used to attack system, and we need to know what those attacks can be. On the other hand the text in draft-ietf-dmarc-aggregate-reporting: Email streams carrying DMARC feedback data MUST conform to the DMARC mechanism, thereby resulting in an aligned "pass" (see Section 3.1). This practice minimizes the risk of report consumers processing fraudulent reports. seems otherwise fine (i.e., saying the DMARC reports MUST be alinged), but the reference "(see Section 3.1)" seems to be invalid. There is no section 3.1 in that draft, and if it is trying to reference to base DMARCbis document, then I think section number is wrong, as 3.1 is "Conventions Used in This Document". I assume it used to refer to "3.1. Identifier Alignment" of "Domain-based Message Authentication, Reporting, and Conformance (DMARC)" RFC7489. If the reports are aligned with DMARC then we can at least filter fake reports out based on the sender if we start receiving such reports from bad actors. > >That's fine, but now that everyone needs to update the XML they produce > >anyway, ... > > Uh, what? If that's what the draft says, we need to fix it since for > obvious reasons, approximately nobody is going to change their report > software. After all, Google is still sending ZIP files. If your expectations is that nobody is going to change their implementations based on new standard track documents, then why are we producing these documents? I actually do at least hope that people will implement the standard track documents, and phase out old implementations which do not implement current non standard track versions... -- kivi...@iki.fi _______________________________________________ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org