Re: [dmarc-ietf] Authentication of reports

["Murray S. Kucherawy" <[e-mail]>]

On Wed, Jan 20, 2021 at 1:21 PM Michael Thomas <[e-mail]> wrote:

> I just scanned through DMARC and I couldn't find any security
> requirements/mechanisms for the failure reports. I would think at the
> very least the receiver consuming the reports ought make certain that
> the report at the very least have either a valid DKIM signature or a SPF
> pass. Unauthenticated data is always the source of mischief, and I'm
> sure that there have to be attacks that are possible with
> unauthenticated reports. At the very least this should be a security
> consideration, and most likely should have some normative language to
> back it up.
>

I thought the usual rules about when you should or shouldn't trust a
message ought to be applied, but I guess we never actually said that in the
document.  We certainly could.

Since I'm sort of new, it's been unclear to me whether whether having a
> new https transport mechanism is in scope or not -- it seems to come up
> pretty often -- but I'm not sure how people would propose to
> authenticate the report sending client. That seems to me to be a basic
> security requirement for any new delivery method. The problem here is
> there isn't a client certificate to determine where the report is coming
> from or any other identifying mechanism. An alternative might be to DKIM
> sign the report itself, but the long and short is that it would need to
> be addressed.
>

As I recall DMARC originally (in its pre-RFC versions) did have "https" as
a supported scheme for "rua", but since nobody implemented it during the
years DMARC was in development, it got dropped before publication.

-MSK