Subject: [dmarc-ietf] Authentication of reports

From: Michael Thomas <[email-masked]>
Date: Wed, 20 Jan 2021 13:21:21 -0800

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.

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.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 20 Jan 2021 14:56:31 -0800

> consideration, and most likely should have some normative language to

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.

> sign the report itself, but the long and short is that it would need to

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

---

From: Seth Blank <[email-masked]>
Date: Wed, 20 Jan 2021 14:59:50 -0800

Michael, please open a ticket. I think you're right and some consideration
around this is needed in the document.

On Wed, Jan 20, 2021 at 2:56 PM Murray S. Kucherawy <[email-masked]>
wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* [email-masked]
*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.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 20 Jan 2021 15:00:57 -0800

On 1/20/21 2:56 PM, Murray S. Kucherawy wrote:
> On Wed, Jan 20, 2021 at 1:21 PM Michael Thomas <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> 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.

> 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

---

From: Michael Thomas <[email-masked]>
Date: Wed, 20 Jan 2021 15:01:55 -0800

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 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     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.
>
>     "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
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/dmarc>
>
>
>
> -- 
> *Seth Blank*| VP, Standards and New Technologies
> *e:[email-masked] <mailto:[email-masked]>
> *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.
>
>

---

From: Seth Blank <[email-masked]>
Date: Wed, 20 Jan 2021 15:08:11 -0800

Discussion is in scope, per: 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 <[email-masked]> wrote:

>> 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
> dmarc mailing [email-masked]://www.ietf.org/mailman/listinfo/dmarc
>

--

---

From: Michael Thomas <[email-masked]>
Date: Wed, 20 Jan 2021 15:10:05 -0800

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>
>
> 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 <[email-masked] 
>>         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.
>>
>>         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
>>     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.
>>
>>
>>     https://www.ietf.org/mailman/listinfo/dmarc  <https://www.ietf.org/mailman/listinfo/dmarc>

---

From: Michael Thomas <[email-masked]>
Date: Wed, 20 Jan 2021 16:01:06 -0800

> that's in scope when either ticket is opened.
Done.

Mike