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

Reply via email to