date:20210126



On 1/26/21 1:44 PM, Todd Herr wrote:
On Tue, Jan 26, 2021 at 4:19 PM Michael Thomas > wrote:


I don't see how time helps anything if I can't differentiate
between our legitimate traffic and attacker traffic. All an
attacker would need to do is send a mail cannon to mimic Marsha in
Marketing every once in a while and the entire thing resets. If it
is a requirement to know all of the legitimate IP addresses in
order to make use of the reports as an indicator, the draft should
be very explicit about that.


Forgive me; I have failed to get my point across in a way that 
conveyed my meaning. Let me try again.


My use of the word "Time" was intended to mean, effectively, 
"experience, wisdom, and knowledge" all of which would be gained 
through regular (for me it was daily) analysis of the latest DMARC 
aggregate reports. Through the time spent analyzing those reports, one 
would obtain a fuller picture of one's organization's mail flows, 
gaining a knowledge that can really only come from immersion in the data.




I have written this up and it is now issue #101.

Mike

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

Re: [dmarc-ietf] attack on reports

On Tue, Jan 26, 2021 at 4:19 PM Michael Thomas  wrote:

> I don't see how time helps anything if I can't differentiate between our
> legitimate traffic and attacker traffic. All an attacker would need to do
> is send a mail cannon to mimic Marsha in Marketing every once in a while
> and the entire thing resets. If it is a requirement to know all of the
> legitimate IP addresses in order to make use of the reports as an
> indicator, the draft should be very explicit about that.
>
>
> Forgive me; I have failed to get my point across in a way that conveyed my
meaning. Let me try again.

My use of the word "Time" was intended to mean, effectively, "experience,
wisdom, and knowledge" all of which would be gained through regular (for me
it was daily) analysis of the latest DMARC aggregate reports. Through the
time spent analyzing those reports, one would obtain a fuller picture of
one's organization's mail flows, gaining a knowledge that can really only
come from immersion in the data.

Once one gets past the first few weeks of the exercise, picking off any
low-hanging fruit, then one settles into a posture of monitoring for
anomalies, expecting to see no failures, and quickly addressing those that
need to be addressed.

At some point, one that is wholly dependent on the complexity of the
infrastructure and the personality of the observer, one becomes comfortable
enough with the data to confidently say, "Now is the time to move to
p=reject" and one makes the move.

After that, there's continued monitoring to make sure that no ill effects
have occurred due to the move, of course, and if there's need to roll back,
one rolls back.

If you're looking for an objective standard by which one can say "If X,
then it is safe to move to p=reject", there really isn't one, save for "If
the domain is newly registered and has never sent mail, then it is safe to
move to p=reject." For any domain that has sent mail prior to the
publishing of a DMARC record, then it's publish, monitor, iterate until one
is ready, and the only standard for that is "When you know, you know."

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:* 703.220.4153

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

Re: [dmarc-ietf] attack on reports




[]

Ok, I think I understand this enough now to write a ticket.

Mike

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

Re: [dmarc-ietf] attack on reports




On 1/26/21 1:01 PM, Steven M Jones wrote:

On 1/26/21 11:24, Michael Thomas wrote:

Here's a very basic question: if I do not know all of the IP addresses
that send on my behalf, are DMARC reports of any value?


No, an organization is not assumed to have perfect knowledge of all
their authorized sending sources. If that were common, there would have
been much less need for DMARC in the first place.


In order to move from p=none to p=reject it seems like you need to know 
that. One of the big advantages of DKIM is that you don't need to have 
know the network configuration of outsiders; you just add a selector for 
them. Not accommodating people who don't or can't know all of the 
legitimate IP addresses seems like a defect in the design/architecture 
of DMARC reporting, and leads to why it can be attacked in the way I 
described.


Mike

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

Re: [dmarc-ietf] attack on reports



On 1/26/21 12:41 PM, Matt V wrote:
On Tue, Jan 26, 2021 at 3:17 PM Michael Thomas > wrote:


How do I know when I'm done though if I don't know the IP
addresses who send on my behalf? Is it an actual forgery or is it
Marsha in marketing using a outsourced email blaster?


This is solved with conversation with the relevant stakeholders in the 
organization from IT, Marketing, PR, etc... along with security and 
brand policies being enforced.


Ultimately only approved and official email sources will be 
authenticated - random sales/marketing people don't get to make those 
types of decisions on the day-to-day. You want an exemption for your 
support/marketing tools you need to get it cleared, vetted and 
properly authenticated to play.


This is how most large companies resolve this issue.


I worked for a large company and that is much easier said than done 
having attempted to do so before the reporting was a twinkle in 
anybody's eye. Hence the low uptake of DMARC. Having to know all of the 
IP addresses that are legitimate senders for your domain is daunting for 
a large enterprise.


Mike

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

Re: [dmarc-ietf] attack on reports



On 1/26/21 12:29 PM, Todd Herr wrote:
On Tue, Jan 26, 2021 at 3:16 PM Michael Thomas > wrote:


Yes, DMARC reports are of value if you don't know all of the IP
addresses that send on your behalf. Some have even written blog
posts on the topic of using DMARC aggregate reports as a tool to
audit one's authentication practices, by publishing a policy of
p=none, collecting the reports, analyzing the data, fixing
problems, iterate, iterate, iterate until one is ready to move on
to the ultimate goal of p=reject.



How do I know when I'm done though if I don't know the IP
addresses who send on my behalf? Is it an actual forgery or is it
Marsha in marketing using a outsourced email blaster?


Time.

Some industry experts have suggested that one budget twelve to 
eighteen months between first publishing a DMARC policy record and the 
hoped-for transition to p=reject. YMMV, and a lot depends on the types 
of messages that the organization sends, and their cadence. At the 
extreme end of more than a year would be larger companies doing 
seasonal or cyclical mailings, ones that maybe only market to certain 
customer segments once or twice per year, tops. The more one knows 
about one's mail flows and the better one's authentication practices 
before deploying DMARC, the shorter that time can be, but a year or 
more isn't unusual at all.


I don't see how time helps anything if I can't differentiate between our 
legitimate traffic and attacker traffic. All an attacker would need to 
do is send a mail cannon to mimic Marsha in Marketing every once in a 
while and the entire thing resets. If it is a requirement to know all of 
the legitimate IP addresses in order to make use of the reports as an 
indicator, the draft should be very explicit about that.


Mike

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

Re: [dmarc-ietf] attack on reports

2021-01-26 Thread Steven M Jones

On 1/26/21 11:24, Michael Thomas wrote:
>
> Here's a very basic question: if I do not know all of the IP addresses
> that send on my behalf, are DMARC reports of any value?
>
No, an organization is not assumed to have perfect knowledge of all
their authorized sending sources. If that were common, there would have
been much less need for DMARC in the first place.

One of the primary goals of DMARC (IMO) is to help organizations
identify sending sources that have to be /investigated/. Some may be
vendors who were engaged outside the normal email operational processes,
most are likely just transient spam sources. But you won't know which is
which until you at least take a cursory look.

All of which requires those DMARC aggregate reports, and benefits from
failure reports if you can get them -- and that the domain owner, or
somebody acting on their behalf, *examines* those reports.

Organizations using email should have at least some policies and
procedures that cover all these things - and that is a very large topic
that this isn't the right place to explore. 

> Enterprises farm out email all of the time and it could be difficult
> to know when they change their server addresses, etc.
>
Yes, which is part of why even organizations that have gone through a
long deployment process and arrived at their desired "end state" find
value in continuing to receive and monitor reports. As you touch on,
vendors don't always tell you about such changes in advance.

You have to examine reports and, from time to time, take some action.

--S.

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

Re: [dmarc-ietf] attack on reports

2021-01-26 Thread Matt V

On Tue, Jan 26, 2021 at 3:17 PM Michael Thomas  wrote:

> How do I know when I'm done though if I don't know the IP addresses who
> send on my behalf? Is it an actual forgery or is it Marsha in marketing
> using a outsourced email blaster?
>

This is solved with conversation with the relevant stakeholders in the
organization from IT, Marketing, PR, etc... along with security and brand
policies being enforced.

Ultimately only approved and official email sources will be authenticated -
random sales/marketing people don't get to make those types of decisions on
the day-to-day. You want an exemption for your support/marketing tools you
need to get it cleared, vetted and properly authenticated to play.

This is how most large companies resolve this issue.

~
*MATTHEW VERNHOUT*
Founder, Editor
EmailKarma.net 
It's not the size of your list, it's how you use it!

t: @emailkarma 
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] attack on reports

On Tue, Jan 26, 2021 at 3:16 PM Michael Thomas  wrote:

>
> On 1/26/21 12:01 PM, Todd Herr wrote:
>
> On Tue, Jan 26, 2021 at 2:24 PM Michael Thomas  wrote:
>
>>
>> On 1/26/21 10:56 AM, Todd Herr wrote:
>>
>>> > In addition, if I recover that message from the log, I might find no
>>> > relationship with the reporting domain or the reported source IP.
>>> > That is to say, I won't be able to deduce if the report is fake or
>>> real.
>>>
>>>
>>> My main point here is to point out the attack.
>>>
>>>
>> The attack scenario you have described relies on several possible but
>> perhaps implausible conditions all being true:
>>
>> 1. There exists a domain run by people who are savvy enough to want to
>> implement DMARC and can consume reports, but don't have a good grasp on
>> which IPs are likely to be theirs and which aren't, and don't have an
>> understanding of how to use common tools to figure out whether an IP
>> address might belong to their provider's ASN or one halfway around the
>> world, and
>>
>> Here's a very basic question: if I do not know all of the IP addresses
>> that send on my behalf, are DMARC reports of any value? Enterprises farm
>> out email all of the time and it could be difficult to know when they
>> change their server addresses, etc. If the reporting is predicated on your
>> having in effect and up to date SPF record (ie, do all of the work to be
>> able to produce one), then that negates anybody who just uses DKIM alone
>> which should be a completely acceptable use case. And no, the
>> domain/selector tells you nothing when it doesn't verify.
>>
>> If it is the case that you MUST know all of your sending IP addresses,
>> that should be in blinking bold right up front in section 7.
>>
>>
>> Yes, DMARC reports are of value if you don't know all of the IP addresses
> that send on your behalf. Some have even written blog posts on the topic of
> using DMARC aggregate reports as a tool to audit one's authentication
> practices, by publishing a policy of p=none, collecting the reports,
> analyzing the data, fixing problems, iterate, iterate, iterate until one is
> ready to move on to the ultimate goal of p=reject.
>
> How do I know when I'm done though if I don't know the IP addresses who
> send on my behalf? Is it an actual forgery or is it Marsha in marketing
> using a outsourced email blaster?
>

Time.

Some industry experts have suggested that one budget twelve to eighteen
months between first publishing a DMARC policy record and the hoped-for
transition to p=reject. YMMV, and a lot depends on the types of messages
that the organization sends, and their cadence. At the extreme end of more
than a year would be larger companies doing seasonal or cyclical mailings,
ones that maybe only market to certain customer segments once or twice per
year, tops. The more one knows about one's mail flows and the better one's
authentication practices before deploying DMARC, the shorter that time can
be, but a year or more isn't unusual at all.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:* 703.220.4153

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

Re: [dmarc-ietf] attack on reports

On 1/26/21 12:01 PM, Todd Herr wrote:
On Tue, Jan 26, 2021 at 2:24 PM Michael Thomas > wrote:

On 1/26/21 10:56 AM, Todd Herr wrote:

> In addition, if I recover that message from the log, I might
find no
> relationship with the reporting domain or the reported
source IP.
> That is to say, I won't be able to deduce if the report is
fake or real.

My main point here is to point out the attack.

The attack scenario you have described relies on several possible
but perhaps implausible conditions all being true:

1. There exists a domain run by people who are savvy enough to
want to implement DMARC and can consume reports, but don't have a
good grasp on which IPs are likely to be theirs and which aren't,
and don't have an understanding of how to use common tools to
figure out whether an IP address might belong to their provider's
ASN or one halfway around the world, and

Here's a very basic question: if I do not know all of the IP
addresses that send on my behalf, are DMARC reports of any value?
Enterprises farm out email all of the time and it could be
difficult to know when they change their server addresses, etc. If
the reporting is predicated on your having in effect and up to
date SPF record (ie, do all of the work to be able to produce
one), then that negates anybody who just uses DKIM alone which
should be a completely acceptable use case. And no, the
domain/selector tells you nothing when it doesn't verify.

If it is the case that you MUST know all of your sending IP
addresses, that should be in blinking bold right up front in
section 7.

Yes, DMARC reports are of value if you don't know all of the IP 
addresses that send on your behalf. Some have even written blog posts 
on the topic of using DMARC aggregate reports as a tool to audit one's 
authentication practices, by publishing a policy of p=none, collecting 
the reports, analyzing the data, fixing problems, iterate, iterate, 
iterate until one is ready to move on to the ultimate goal of p=reject.

How do I know when I'm done though if I don't know the IP addresses who 
send on my behalf? Is it an actual forgery or is it Marsha in marketing 
using a outsourced email blaster?

The larger point is that I should not have had to come to a working 
group mailing list to find out what should be in the document in the 
first place. Along with some ascii art in 7.2, there needs to be some 
explanation of the reporting's applicability and limitations. It doesn't 
need to be tome but some informative text goes a long way to helping 
people out who we're involved with the document from the beginning.

Mike

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

Re: [dmarc-ietf] attack on reports

On Tue, Jan 26, 2021 at 2:24 PM Michael Thomas  wrote:

>
> On 1/26/21 10:56 AM, Todd Herr wrote:
>
>> > In addition, if I recover that message from the log, I might find no
>> > relationship with the reporting domain or the reported source IP.
>> > That is to say, I won't be able to deduce if the report is fake or real.
>>
>>
>> My main point here is to point out the attack.
>>
>>
> The attack scenario you have described relies on several possible but
> perhaps implausible conditions all being true:
>
> 1. There exists a domain run by people who are savvy enough to want to
> implement DMARC and can consume reports, but don't have a good grasp on
> which IPs are likely to be theirs and which aren't, and don't have an
> understanding of how to use common tools to figure out whether an IP
> address might belong to their provider's ASN or one halfway around the
> world, and
>
> Here's a very basic question: if I do not know all of the IP addresses
> that send on my behalf, are DMARC reports of any value? Enterprises farm
> out email all of the time and it could be difficult to know when they
> change their server addresses, etc. If the reporting is predicated on your
> having in effect and up to date SPF record (ie, do all of the work to be
> able to produce one), then that negates anybody who just uses DKIM alone
> which should be a completely acceptable use case. And no, the
> domain/selector tells you nothing when it doesn't verify.
>
> If it is the case that you MUST know all of your sending IP addresses,
> that should be in blinking bold right up front in section 7.
>
>
> Yes, DMARC reports are of value if you don't know all of the IP addresses
that send on your behalf. Some have even written blog posts on the topic of
using DMARC aggregate reports as a tool to audit one's authentication
practices, by publishing a policy of p=none, collecting the reports,
analyzing the data, fixing problems, iterate, iterate, iterate until one is
ready to move on to the ultimate goal of p=reject.

In my experience, there is enough information in the DMARC aggregate
reports to allow for someone to make an educated guess as to whether an IP
that's generating mail that's not authenticating is perhaps a server
sending reports from the side of the desk of Emily in Engineering, or a
third party that Mike in Marketing contracted to send mail on the company's
behalf, or whether it's almost certainly an IP that's not one used by the
organization at all. This presumes, of course, that one at least has a clue
as to what public IP range(s) are in use by the organization, not just for
mail but for general connectivity, but with the security organization
and/or IT typically running (or at least ordering and participating in the
analysis of) the DMARC deployment, that seems a safe assumption. Having the
source IP in the aggregate report isn't necessarily just to make sure it
gets added to the SPF record, either; many times it (along with the other
information in that tuple) gives the report consumer a clue as to where to
start hunting in his infrastructure for the MTA that isn't correctly DKIM
signing mail at this time.

As to third parties changing email addresses all the time, you're correct,
they do, but they mitigate the impact on their customers by instructing
them to use the include: mechanism in their SPF records, rather than trying
to enumerate all of the vendor's IP ranges, e.g., include:_
spf.salesforce.com, include:_spf.google.com, etc.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:* 703.220.4153

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

Re: [dmarc-ietf] attack on reports

On 1/26/21 10:56 AM, Todd Herr wrote:

> In addition, if I recover that message from the log, I might find no
> relationship with the reporting domain or the reported source IP.
> That is to say, I won't be able to deduce if the report is fake
   or real.

   My main point here is to point out the attack.

The attack scenario you have described relies on several possible but 
perhaps implausible conditions all being true:

1. There exists a domain run by people who are savvy enough to want to 
implement DMARC and can consume reports, but don't have a good grasp 
on which IPs are likely to be theirs and which aren't, and don't have 
an understanding of how to use common tools to figure out whether an 
IP address might belong to their provider's ASN or one halfway around 
the world, and

Here's a very basic question: if I do not know all of the IP addresses 
that send on my behalf, are DMARC reports of any value? Enterprises farm 
out email all of the time and it could be difficult to know when they 
change their server addresses, etc. If the reporting is predicated on 
your having in effect and up to date SPF record (ie, do all of the work 
to be able to produce one), then that negates anybody who just uses DKIM 
alone which should be a completely acceptable use case. And no, the 
domain/selector tells you nothing when it doesn't verify.

If it is the case that you MUST know all of your sending IP addresses, 
that should be in blinking bold right up front in section 7.

Mike

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

[dmarc-ietf] understanding section 7.2




So I'm an outsider who has not tried to digest what's going on in the 
reports until recently so my eyes are fresh. Basically section 7.2 is 
extremely hard to understand what is in the reports. I know that the XML 
is what ought to be normative, but a little bit of ascii art could go a 
long way to helping people understand what the reports do and don't 
have. I've been staring at the XML all morning trying to understand it 
and it is very difficult when all you're trying to do is figure out what 
the reports supply or not. It would be extremely helpful to layout what 
is in each record for human consumption to just understand what the 
reports do and don't contain.


Mike

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

[dmarc-ietf] nit in section 7.2


"The report SHOULD include the following data:"

Normative SHOULD here since very strange because what follows is informational, 
and why would it be SHOULD in the first place?

It seems to me it ought to be:

"The report includes the following data:"

If there are normative requirements, it seems like it would be better to put it 
into the XML section itself.
 
Mike


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

Re: [dmarc-ietf] attack on reports

On Tue, Jan 26, 2021 at 1:01 PM Michael Thomas  wrote:

>
> On 1/26/21 9:37 AM, Alessandro Vesely wrote:
> > On Tue 26/Jan/2021 18:24:53 +0100 Michael Thomas wrote:
> >>
> >> This is different than yesterday. From what I can tell there is no
> >> identifying information of the original message like message-id in
> >> the report xml. If i'm wrong, please point me to it.
> >
> >
> > With a record for each message it wouldn't be an *aggregate* report.
>
>
>  From section 7.2:
>
> "Visibility comes in the form of daily (or more frequent) Mail
> Receiver-originated feedback reports that contain aggregate data on
> message streams relevant to the Domain Owner. This information includes
> data about messages that passed DMARC authentication as well as those
> that did not."
>
> That sure sounds like it's on a message basis to me. How else could the
> reports get to be as big as megabytes?
>

I don't believe they do reach megabytes in size. I wasn't present at the
creation, but I believe that the 10MB size limit was chosen as one to allow
for more than enough headroom for aggregate reports.

Adding message-ids to aggregate reports removes the aggregation feature of
the report, and would be an undue burden both for the report generator and
the report consumer, in my opinion, mostly due to the orders of magnitude
increase in storing the data. For example, where today I can represent
50,000 messages in one row in my data store based on the aggregation of
source IP, policy_evaluated, identifier, and auth_results I would instead
require 50,000 rows to do the same if message-ids were added to the
reports. Aggregate reports aren't used to troubleshoot authentication
failures for individual messages; they're meant to convey information about
whether a sending IP is transmitting messages that generally pass or fail
SPF and DKIM checks. If a source
IP/policy_evaludated/identifier/auth_results tuple shows as failing
authentication checks a high percentage of the time, and the source IP is
known to be one used by the organization, then that mailstream can be
examined and corrected.

>
>
> >
> > In addition, if I recover that message from the log, I might find no
> > relationship with the reporting domain or the reported source IP.
> > That is to say, I won't be able to deduce if the report is fake or real.
>
>
> My main point here is to point out the attack.
>
>
The attack scenario you have described relies on several possible but
perhaps implausible conditions all being true:

1. There exists a domain run by people who are savvy enough to want to
implement DMARC and can consume reports, but don't have a good grasp on
which IPs are likely to be theirs and which aren't, and don't have an
understanding of how to use common tools to figure out whether an IP
address might belong to their provider's ASN or one halfway around the
world, and
2. $LARGEPROVIDER is sophisticated enough to do DMARC validation and
reporting, but not so sophisticated as to notice that the bombardment of
mail generated by the criminal is different from other flows using that
domain, and so therefore won't take action to cut off its acceptance of
that flow in ways that would cause it to not be reported on (i.e., blocking
the source not because of DMARC, but because it's a known spam source, and
so the messages are never accepted nor run through DMARC validation
checks), and
3. There exists a criminal who, given the choice of squeezing through the
eye of a needle by somehow preventing a domain from reaching a p=reject
policy (which isn't always honored, anyway) using this bombardment
technique or driving a truck through the chasm of using cousin domains or
even look-alike domains that include homoglyphs that render them apparently
identical to the target domain (a problem DMARC is not designed to solve)
will choose the more difficult path.

I would think this scenario much more likely if DMARC were at this time a
purely hypothetical exercise. Given that we're years into implementation
already, I'm less confident that the above three conditions all exist at
the same time.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:* 703.220.4153

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

Re: [dmarc-ietf] attack on reports



On 1/26/21 9:37 AM, Alessandro Vesely wrote:

On Tue 26/Jan/2021 18:24:53 +0100 Michael Thomas wrote:


This is different than yesterday. From what I can tell there is no 
identifying information of the original message like message-id in 
the report xml. If i'm wrong, please point me to it.



With a record for each message it wouldn't be an *aggregate* report.



From section 7.2:

"Visibility comes in the form of daily (or more frequent) Mail 
Receiver-originated feedback reports that contain aggregate data on 
message streams relevant to the Domain Owner. This information includes 
data about messages that passed DMARC authentication as well as those 
that did not."


That sure sounds like it's on a message basis to me. How else could the 
reports get to be as big as megabytes?





In addition, if I recover that message from the log, I might find no 
relationship with the reporting domain or the reported source IP.  
That is to say, I won't be able to deduce if the report is fake or real.



My main point here is to point out the attack.

Mike

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

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

2021-01-26 Thread John R Levine

Doing it now might overload the WG.  If DKIM for binary has its own merit, we 
can just hypothesize we'll do.  Meanwhile we can mention it and suggest to 
use it for https: when it comes, if ever.  After all, that's what RFC 2045 
does with "binary".


Since client certificates exist and http DKIM signatures do not, that 
doesn't sound like a great plan.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [dmarc-ietf] attack on reports


On Tue 26/Jan/2021 18:24:53 +0100 Michael Thomas wrote:


This is different than yesterday. From what I can tell there is no identifying 
information of the original message like message-id in the report xml. If i'm 
wrong, please point me to it.



With a record for each message it wouldn't be an *aggregate* report.

In addition, if I recover that message from the log, I might find no 
relationship with the reporting domain or the reported source IP.  That is to 
say, I won't be able to deduce if the report is fake or real.




Since the object of the reports is to have confidence so that I can set a
p=reject policy, all an attacker needs to do is bombard $LARGEPROVIDER with
bogus messages purportedly from my domain to make me not want to change over
to reject for fear of large providers dumping legitimate email from my
domain. This could be somewhat mitigated if you know all of the IP addresses
that send for you domain, but that could be difficult with the use of
outsourced email, etc and shouldn't be a requirement.


$LARGEPROVIDER must use a reputation system to evaluate both the report 
generator domain and the reported IP numbers.




Addition of the message-id would allow me to cross check from my logs, say,
that it was a legitimate message from my domain or not.


Not if you take forwarding into account.


Best
Ale
--
















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

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality



On 1/26/21 9:16 AM, John R Levine wrote:


Even if you can deduce a From: email address after the Subject Alt 
Name, you cannot reliably associate it to an organizational domain.


Sorry, that makes no sense at all.  The cert has a domain name, or a 
bunch of domain names.  You can do exactly as much or as little with 
those domain names as you can with the domain in an e-mail From: 
header.  Keep in mind, of course, that none of those domains have any 
connection at all with the contents of an aggregate report, no matter 
how it is delivered.




Use of client certs is a non-starter. The use of http here is 
problematic and getting more so. This entire issue should just be junked.


Mike

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

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality


On Tue 26/Jan/2021 18:23:35 +0100 Murray S. Kucherawy wrote:

On Tue, Jan 26, 2021 at 9:16 AM John R Levine  wrote:


Sheesh.  That isn't mission creep, it's mission gallop.

The spec can be commissioned to a narrowly focused WG (like dcrup).


Really, no.  It's something we might think about on its own merits some
other time, but its absurd to try to do it as a detour from DMARC.


+1.  I don't see why we wouldn't just recharter this group (if that would
even be necessary) to do it.  The right audience is already here.



Doing it now might overload the WG.  If DKIM for binary has its own merit, we 
can just hypothesize we'll do.  Meanwhile we can mention it and suggest to use 
it for https: when it comes, if ever.  After all, that's what RFC 2045 does 
with "binary".



Best
Ale
--














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

[dmarc-ietf] attack on reports




This is different than yesterday. From what I can tell there is no 
identifying information of the original message like message-id in the 
report xml. If i'm wrong, please point me to it. Since the object of the 
reports is to have confidence so that I can set a p=reject policy, all 
an attacker needs to do is bombard $LARGEPROVIDER with bogus messages 
purportedly from my domain to make me not want to change over to reject 
for fear of large providers dumping legitimate email from my domain. 
This could be somewhat mitigated if you know all of the IP addresses 
that send for you domain, but that could be difficult with the use of 
outsourced email, etc and shouldn't be a requirement. Addition of the 
message-id would allow me to cross check from my logs, say, that it was 
a legitimate message from my domain or not. There may be other ways to 
solve this, but that is one.


Mike

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

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

2021-01-26 Thread Murray S. Kucherawy

On Tue, Jan 26, 2021 at 9:16 AM John R Levine  wrote:

> >> Sheesh.  That isn't mission creep, it's mission gallop.
> > The spec can be commissioned to a narrowly focused WG (like dcrup).
>
> Really, no.  It's something we might think about on its own merits some
> other time, but its absurd to try to do it as a detour from DMARC.
>

+1.  I don't see why we wouldn't just recharter this group (if that would
even be necessary) to do it.  The right audience is already here.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

2021-01-26 Thread John R Levine


On Tue, 26 Jan 2021, Alessandro Vesely wrote:

Won't we put a DKIM-Signature: in the http: header?



Sheesh.  That isn't mission creep, it's mission gallop.

The spec can be commissioned to a narrowly focused WG (like dcrup).


Really, no.  It's something we might think about on its own merits some 
other time, but its absurd to try to do it as a detour from DMARC.



If you want a domain identity (even though in this case it provides
nothing useful), what's wrong with a client cert? They exist, they
work, they have software support everywhere.


Even if you can deduce a From: email address after the Subject Alt Name, you 
cannot reliably associate it to an organizational domain.


Sorry, that makes no sense at all.  The cert has a domain name, or a bunch 
of domain names.  You can do exactly as much or as little with those 
domain names as you can with the domain in an e-mail From: header.  Keep 
in mind, of course, that none of those domains have any connection at all 
with the contents of an aggregate report, no matter how it is delivered.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [dmarc-ietf] Which DKIM(s) should be reported? (Ticket #38)


On Tue 26/Jan/2021 15:12:57 +0100 Douglas Foster wrote:
At some point, an investigator will ask, "which of our systems sent these 
messages?"



Possibly none.  In that case this is either an abuse or a forward.  Or maybe 
the report generator lies.




I know how to search my logs for messages to domain example.com I do not
know how to search my logs for messages to domains hosted by
hostingservice.tld.  That is why I would expect SMTP To domain to be
useful.


A smart relay can put together in the same message several RCPT commands with 
different domains having the same MX.



An rua report is not supposed to be substitute for a forensic report.  All 
possible details are not supposed to be presented.  Source IP, SMTP MailFrom 
domain, and SPF status should be sufficient to identify the organization 
responsible for the last hop.  Why is additional mailflow data necessary?



In case of forwarding, the last hop is likely not to be aligned.  Previously in 
this thread you said reporting aligned identifiers only would suffice.  Aligned 
and last hop don't necessarily match.



The best mail flow data would be to report the entire Received chain, but it 
would cause too much disaggregation.



If every receiver generated aggregate reports, senders would get the whole 
chain, in different reports.



Best
Ale
--




















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

Re: [dmarc-ietf] Ticket #1 - SPF alignment


On Tue 26/Jan/2021 14:14:45 +0100 Scott Kitterman wrote:

On Tuesday, January 26, 2021 6:54:56 AM EST Alessandro Vesely wrote:

On Mon 25/Jan/2021 22:35:09 +0100 Scott Kitterman wrote:

On Monday, January 25, 2021 4:04:33 PM EST Todd Herr wrote:

May I propose that the section labeled "SPF-Authenticated Identifiers" be
rewritten as follows:

[...]

   The reader should note that SPF alignment checks in DMARC rely solely
   on the RFC5321.MailFrom domain. This differs from section 2.3 of
   [@!RFC7208], which recommends that SPF checks be done on not only the
   "MAIL FROM" but also on a separate check of the "HELO" identity. >


I think this is fine, but there is a subtlety to be aware of.

If you look at RFC 7208 Section 2.4, when Mail From is null,
postmaster@HELO is the mail from for SPF purposes.  DMARC really can't
change that.

As a result, there are cases where Mail From results actually are derived
from HELO and it's unavoidable.


I doubt that SPF filters report envelope-from=postmaster@HELO; more likely
they write helo=HELO.  In that case, the paragraph quoted above is
deceptive.

I believe the proposed text is clear enough about not using separate HELO
identity results and that's appropriate.


My filter collects SPF results recorded from an upstream SPF filter.  It
writes Received-SPF: lines for each identity.  For NDNs, it writes a
Received-SPF: for the HELO identity only.  Am I allowed to use that result
for DMARC?


No.  You should only use Mail From results.



So NDNs having only an aligned HELO will never pass DMARC?

And what is a helo element in aggregate reports provided for?

The spec says:

 [SPF] can authenticate either the domain that appears in the
   RFC5321.MailFrom (MAIL FROM) portion of [SMTP] or the RFC5321.EHLO/
   HELO domain, or both.

And then:

   In relaxed mode, the [SPF]-authenticated domain and RFC5322.From
   domain must have the same Organizational Domain.  In strict mode,
   only an exact DNS domain match is considered to produce Identifier
   Alignment.

So, consider the following message without DKIM signatures:

HELO example.org
MAIL FROM:

Received-SPF: pass (domain example.org
  designates 192.0.2.1 as permitted sender)
  identity=helo; helo=example.org;
Received-SPF: fail (domain of u...@example.com
  denies 192.0.2.1 as permitted sender)
  identity=mailfrom; envelope-from="u...@example.com";
Subject: Not using a mail client for this example
From: different-u...@example.org

Does it pass DMARC?

Best
Ale
--





















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

Re: [dmarc-ietf] Which DKIM(s) should be reported? (Ticket #38)

2021-01-26 Thread Douglas Foster

At some point, an investigator will ask, "which of our systems sent these
messages?"

I know how to search my logs for messages to domain example.com.  I do not
know how to search my logs for messages to domains hosted by
hostingservice.tld.  That is why I would expect SMTP To domain to be useful.

An rua report is not supposed to be substitute for a forensic report,.  All
possible details are not supposed to be presented.  Source IP, SMTP
MailFrom domain, and SPF status should be sufficient to identify the
organization responsible for the last hop.  Why is additional mailflow data
necessary?

The best mail flow data would be to report the entire Received chain, but
it would cause too much disaggregation.

On Tue, Jan 26, 2021, 7:50 AM Alessandro Vesely  wrote:

> On Tue 26/Jan/2021 13:02:46 +0100 Douglas Foster wrote:
> > DKIM Scopes
> > I have not heard a compelling argument to require information about
> > authentication tests that are unrelated to alignment testing.For
> DKIM
> > specifically, I think one scope should be sufficient, on this hierarchy:
> >
> > - The best-aligned scope that verified, or
> > - the best-aligned scope that failed verification, or
> > - a no-signature result otherwise.
> >
> > Anything more complex imposes a gratuitous data collection burden on the
> > reporting domain and reduces aggregation significantly.   On the
> technical
> > side, it has already been noted that variable-length lists are
> particularly
> > problematic for calculating aggregates.
>
>
> Let me attach an HTML rendering of a report I received today, so we can
> talk
> about something real.
>
> Lines with IP 4.31.198.44 bear a ietf.org identifier.  I see no reason to
> remove it.  It is useful for understanding the mailflow, which is what
> DMARC
> reporting is designed to do.
>
>
> > Aggregation Controls
> >
> > We have discussed whether the target domain should be included in the
> > report.  I understand that doing so is not reasonable for the large
> hosting
> > services.   On the other hand, including the target domain would be a
> > trivial matter for smaller operations, and I think it would be valuable
> for
> > some research.Similarly, DKIM scopes are known to be useful for most
> > investigations, but John has already observed that proliferation of DKIM
> > scopes can be used to force disaggregation down to the individual
> recipient
> > level.
>
>
> Even if this is a small example, learning the disaggregated, or even
> individual
> recipients does not help my understanding.  Authentication is obviously
> conditioned by how the Mediator treats my messages.
>
> I expect that Fastmail Pty Ltd carries out SPF and DKIM validation using
> the
> same algorithm, irrespective of the recipient.  That is what I, as a
> sender, am
> interested in.  Splitting the report in 66 lines wouldn't tell me anything
> more, it would just consume more eyeballs.  And is useless for people who
> sum
> up all reports and just look at the totals.  In any case, I cannot verify
> if
> the messages I didn't send directly are real.
>
> If a multi-domain host allows personalized validation algorithms for some
> domains, I'd expect they send separated aggregate reports, if any.
>
>
> Best
> Ale
> --
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #1 - SPF alignment

2021-01-26 Thread Scott Kitterman

On Tuesday, January 26, 2021 6:54:56 AM EST Alessandro Vesely wrote:
> On Mon 25/Jan/2021 22:35:09 +0100 Scott Kitterman wrote:
> > On Monday, January 25, 2021 4:04:33 PM EST Todd Herr wrote:
> >> May I propose that the section labeled "SPF-Authenticated Identifiers" be
> >> rewritten as follows:
> >> 
> >> [...]
> >> 
> >>The reader should note that SPF alignment checks in DMARC rely solely
> >>on the RFC5321.MailFrom domain. This differs from section 2.3 of
> >>[@!RFC7208], which recommends that SPF checks be done on not only the
> >>"MAIL FROM" but also on a separate check of the "HELO" identity. >
> > 
> > I think this is fine, but there is a subtlety to be aware of.
> > 
> > If you look at RFC 7208 Section 2.4, when Mail From is null,
> > postmaster@HELO is the mail from for SPF purposes.  DMARC really can't
> > change that.
> > 
> > As a result, there are cases where Mail From results actually are derived
> > from HELO and it's unavoidable.
> 
> I doubt that SPF filters report envelope-from=postmaster@HELO; more likely
> they write helo=HELO.  In that case, the paragraph quoted above is
> deceptive.
> > I believe the proposed text is clear enough about not using separate HELO
> > identity results and that's appropriate.
> 
> My filter collects SPF results recorded from an upstream SPF filter.  It
> writes Received-SPF: lines for each identity.  For NDNs, it writes a
> Received-SPF: for the HELO identity only.  Am I allowed to use that result
> for DMARC?

No.  You should only use Mail From results.

Scott K



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

Re: [dmarc-ietf] Which DKIM(s) should be reported? (Ticket #38)

On Tue 26/Jan/2021 13:02:46 +0100 Douglas Foster wrote:

DKIM Scopes
I have not heard a compelling argument to require information about
authentication tests that are unrelated to alignment testing. For DKIM
specifically, I think one scope should be sufficient, on this hierarchy:

- The best-aligned scope that verified, or
- the best-aligned scope that failed verification, or
- a no-signature result otherwise.

Anything more complex imposes a gratuitous data collection burden on the
reporting domain and reduces aggregation significantly. On the technical
side, it has already been noted that variable-length lists are particularly
problematic for calculating aggregates.

Let me attach an HTML rendering of a report I received today, so we can talk
about something real.

Lines with IP 4.31.198.44 bear a ietf.org identifier. I see no reason to
remove it. It is useful for understanding the mailflow, which is what DMARC
reporting is designed to do.

Aggregation Controls

We have discussed whether the target domain should be included in the
report. I understand that doing so is not reasonable for the large hosting
services. On the other hand, including the target domain would be a
trivial matter for smaller operations, and I think it would be valuable for
some research.Similarly, DKIM scopes are known to be useful for most
investigations, but John has already observed that proliferation of DKIM
scopes can be used to force disaggregation down to the individual recipient
level.

Even if this is a small example, learning the disaggregated, or even individual
recipients does not help my understanding. Authentication is obviously
conditioned by how the Mediator treats my messages.

I expect that Fastmail Pty Ltd carries out SPF and DKIM validation using the
same algorithm, irrespective of the recipient. That is what I, as a sender, am
interested in. Splitting the report in 66 lines wouldn't tell me anything
more, it would just consume more eyeballs. And is useless for people who sum
up all reports and just look at the totals. In any case, I cannot verify if
the messages I didn't send directly are real.

If a multi-domain host allows personalized validation algorithms for some
domains, I'd expect they send separated aggregate reports, if any.

Best
Ale
--

Title:
Feedback from
Fastmail Pty Ltd

Feedback from
Fastmail Pty LtdId: 419588072; begin: 2021-01-25T00:00:00Z; end: 2021-01-25T23:59:59ZDomain: tana.it; DKIM: ; SPF: ; policy published: none none 100
Relaying IP

message count

reason and disposition

From header

(opt. envelope)

SPF

DKIM

2nd DKIM

3rd DKIM

62.94.243.2261tana.ittana.itmfromtana.itdeltapass
4.31.198.4415trusted_forwarder Policy ignored due to local white listtana.itietf.orgmfromietf.orgietf1passietf.orgietf1passtana.itdeltafail (body has been altered)
4.31.198.4450tana.itietf.orgmfromietf.orgietf1passietf.orgietf1passtana.itdeltapass
Legend
disposition: quarantine,
reject.spf: pass,
fail,
softfail,
temperror or permerror.dkim: pass,
fail,
policy.

This is a DMARC aggregate report for tana.it

3 records.
2 passed.
1 failed.

Submitted by Fastmail Pty Ltd
Generated with Mail::DMARC 1.20180917

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

Re: [dmarc-ietf] Which DKIM(s) should be reported? (Ticket #38)

2021-01-26 Thread Douglas Foster

This topic becomes much more than "which signature".   It is really about
"what is needed to identify and correct alignment problems".

Based on the authentication discussion, we have several inter-related
issues:
- I started with a concern about putting excessive data collection
requirements on the reporting domain.

- Increased data collection causes data disaggregation.   This becomes a
technical problem as report sizes increase.   Disaggregation also allows
individual message characteristics to be revealed, which becomes a
potential privacy concern.

- In theory, very few attributes should be necessary to triage an alignment
problem:  Source IP, SMTP domain, From Domain, and DKIM scope.  In
practice, investigating root cause is difficult and as a result report
recipients crave maximum data.

My current perspective, still open to being convinced

DKIM Scopes
I have not heard a compelling argument to require information about
authentication tests that are unrelated to alignment testing.For DKIM
specifically, I think one scope should be sufficient, on this hierarchy:

- The best-aligned scope that verified, or
- the best-aligned scope that failed verification, or
- a no-signature result otherwise.

Anything more complex imposes a gratuitous data collection burden on the
reporting domain and reduces aggregation significantly.   On the technical
side, it has already been noted that variable-length lists are particularly
problematic for calculating aggregates.

I would also suggest dropping the requirement to include all authentication
test results.   Only SPF and aligned DKIM are relevant, and anything more
causes disaggregation.

Aggregation Controls

We have discussed whether the target domain should be included in the
report.  I understand that doing so is not reasonable for the large hosting
services.   On the other hand, including the target domain would be a
trivial matter for smaller operations, and I think it would be valuable for
some research.Similarly, DKIM scopes are known to be useful for most
investigations, but John has already observed that proliferation of DKIM
scopes can be used to force disaggregation down to the individual recipient
level.

I wonder if the solution to both of these is to use variable aggregation.
  When the number of target domains is small, reporting the source domain
is probably not an issue for either the report sender or the report
receiver.So we could make the field optional, where some organizations
report an actual target domain and others report a placeholder, with the
level of aggregation chosen by the needs of the reporting organization and
by overall constraints on report size (probably based on number of result
rows).  The same could apply to DKIM:   If disaggregation by DKIM scope
provides a report that is too large, the scope can be replaced with a
placeholder to increase aggregation and reduce report size.

DF

On Mon, Jan 25, 2021 at 1:38 PM Alessandro Vesely  wrote:

> On Mon 25/Jan/2021 18:59:16 +0100 Brotman, Alex wrote:
> >
> > I’m not suggesting that we add anything that would report “Signature
> > validation not attempted”, that sounds horrible.  Will the original
> source
> > potentially care that the message was signed in three other places as the
> > message bounced around?
>
> It can be useful to understand the mail flow.  For example, a signature by
> a
> Mediator can reveal a mailing list, even if the receiver didn't evaluate
> it.
>
>
> > Should we put the onus on the reporting entity to do the filter out the
> > non-aligned (what if none aligned) signatures, or just realize it’s some
> > automated job and including all logged/validated signatures is the better
> > way?
>
> The order in which signatures appear in a report can be significant too.
>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #1 - SPF alignment


On Mon 25/Jan/2021 22:35:09 +0100 Scott Kitterman wrote:

On Monday, January 25, 2021 4:04:33 PM EST Todd Herr wrote:


May I propose that the section labeled "SPF-Authenticated Identifiers" be
rewritten as follows:

[...]

   The reader should note that SPF alignment checks in DMARC rely solely
   on the RFC5321.MailFrom domain. This differs from section 2.3 of 
   [@!RFC7208], which recommends that SPF checks be done on not only the

   "MAIL FROM" but also on a separate check of the "HELO" identity. >

I think this is fine, but there is a subtlety to be aware of.

If you look at RFC 7208 Section 2.4, when Mail From is null, postmaster@HELO
is the mail from for SPF purposes.  DMARC really can't change that.

As a result, there are cases where Mail From results actually are derived from
HELO and it's unavoidable.



I doubt that SPF filters report envelope-from=postmaster@HELO; more likely they 
write helo=HELO.  In that case, the paragraph quoted above is deceptive.




I believe the proposed text is clear enough about not using separate HELO
identity results and that's appropriate.


My filter collects SPF results recorded from an upstream SPF filter.  It writes 
Received-SPF: lines for each identity.  For NDNs, it writes a Received-SPF: for 
the HELO identity only.  Am I allowed to use that result for DMARC?



Best
Ale
--

















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

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality