Re: [dmarc-ietf] Authentication of reports

[Michael Thomas <[e-mail]>]

Ok, i'll break it into two separate issues as they are related but not 
the same.

Mike

On 1/20/21 3:08 PM, Seth Blank wrote:
> Discussion is in scope, per: 
> https://trac.ietf.org/trac/dmarc/ticket/42 
> <https://trac.ietf.org/trac/dmarc/ticket/42>
>
> This topic has come up before, and there's always general interest in 
> pursuing it, and absolutely no one who puts their hand up for either 
> it being impactful for them or having any interest in implementing it. 
> i.e. it seems interesting to people, but there seems to be no use case 
> with operational support to actually add it.
>
> So from those previous discussions, I don't think it's likely that 
> we'll add reporting beyond mailto:, but it is certainly a conversation 
> that's in scope when either ticket is opened.
>
> Seth
>
> On Wed, Jan 20, 2021 at 3:02 PM Michael Thomas <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>
>     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
>>     <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>         On Wed, Jan 20, 2021 at 1:21 PM Michael Thomas <[e-mail]
>>         <mailto:[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
>>         _______________________________________________
>>         dmarc mailing list
>>         [e-mail] <mailto:[e-mail]>
>>         https://www.ietf.org/mailman/listinfo/dmarc
>>         <https://www.ietf.org/mailman/listinfo/dmarc>
>>
>>
>>
>>     -- 
>>     *Seth Blank*| VP, Standards and New Technologies
>>     *e:*[e-mail] <mailto:[e-mail]>
>>     *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
>>     [e-mail]  <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/dmarc  <https://www.ietf.org/mailman/listinfo/dmarc>
>     _______________________________________________
>     dmarc mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/dmarc
>     <https://www.ietf.org/mailman/listinfo/dmarc>
>
>
>
> -- 
> *Seth Blank*| VP, Standards and New Technologies
> *e:*[e-mail] <mailto:[e-mail]>
> *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.
>