On 1/20/21 2:59 PM, Seth Blank wrote:
Michael, please open a ticket. I think you're right and some consideration around this is needed in the document.

What about the https part? If it's not in scope I don't want to add noise.

Mike


On Wed, Jan 20, 2021 at 2:56 PM Murray S. Kucherawy <superu...@gmail.com <mailto:superu...@gmail.com>> wrote:

    On Wed, Jan 20, 2021 at 1:21 PM Michael Thomas <m...@mtcc.com
    <mailto:m...@mtcc.com>> 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
    _______________________________________________
    dmarc mailing list
    dmarc@ietf.org <mailto:dmarc@ietf.org>
    https://www.ietf.org/mailman/listinfo/dmarc
    <https://www.ietf.org/mailman/listinfo/dmarc>



--
*Seth Blank*| VP, Standards and New Technologies
*e:*s...@valimail.com <mailto:s...@valimail.com>
*p:*415.273.8818


This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.


_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to