On 1/20/21 2:56 PM, Murray S. Kucherawy wrote:
On Wed, Jan 20, 2021 at 1:21 PM Michael Thomas <[email protected]
<mailto:[email protected]>> 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.
DKIM is pretty nebulous about what it's results should used for, but as
an authentication mechanism for another protocol it seem like it would
be good say that explicitly. In this case it's a little more complicated
since the thing processing the reports is almost certainly not at the
boundary MTA verifying signatures.
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.
So is it in scope or not? It's confusing if it's not because there seem
to have been several open tickets about it.
Mike
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
