Re: [dmarc-ietf] Aggregate reporting - one DKIM signature

[Douglas Foster <[e-mail]>]

Let's skip past the wording issues and head to the core issue:   one
signature or many?

Ale has restated the conventional wisdom, which is based on intuition:
 more data is always better than less data.    Only a few weeks ago, I
accepted that axiom.   But the conventional wisdom does not hold up to
scrutiny.    Server identity, MailFrom identity, and one aligned signature
provide all of the data needed.

Identifying and configuring authorized servers:

First, cull out data servers that pass DMARC on both SPF and DKIM.   This
mail was received directly and the source servers are properly configured.

Second, cull out the data for servers that pass aligned SPF but not DKIM.
 These appear to be internally-controlled servers that do not apply correct
DKIM signatures.   Find them and assign a DKIM scope ID.  This will reduce
the number of suspect servers because non-altering forwards will begin
producing DMARC PASS.   Of course, if your SPF scope is allowing an
unauthorized server to send messages on your behalf, fix your SPF record
and fire the vendor who broke your trust.

Third, if an IP address is identified as under organization control but not
passing SPF, find and fix the problem with your SPF record, as well as
assigning a DKIM scope ID.

Fourth, identify messages from well-known email service providers.   These
vendors do not forward and do not impersonate.  If you see a
ConstantContact server sending unsigned mail for your domain, you can know
that somebody in your organization has hired them to do so.   Find that
person and assign a DKIM scope ID.

That should be enough to identify all authorized servers.


Evaluating unauthorized servers

Once all authorized servers are identified and properly configured, we can
move onto the possibility of evaluating unauthorized servers.   The IP
representing a source of unauthenticated messages can be playing one of
three roles:
- It originated an unauthenticated message.
- It received an authenticated message but made alterations that caused it
to lose authentication.
- It received an unauthenticated message and chose to deliver it anyway.

In the first and second case, the reported server is fully responsible for
the unauthenticated state of the message.   In the third case, if the
message is malicious, then the reported server is guilty of reckless
forwarding.   The last case is also the least important, because forwarding
is a tiny portion of the total mail stream.   Whatever source is hidden by
reckless forwarding, it will be exposed by all of the unauthorized messages
that are received directly.

Of course, some unauthenticated mail is malicious and some is wanted.
 Evaluators carry the responsibility of protecting their users from
unwanted email.   If a reporting system consistently accepts
unauthenticated messages from a particular IP address, server organization,
or MailFrom domain, then they may have determined that those messages are
wanted and non-malicious.  So acceptance behavior helps to segregate
acceptable sources from malevolent ones.

None of this requires unaligned signatures.  If there is a case when those
extra signatures are important, please present it.

Doug Foster



On Mon, Oct 31, 2022 at 8:36 AM Alessandro Vesely <[e-mail]> wrote:

> On Sun 30/Oct/2022 19:31:04 +0100 Douglas Foster wrote:
> > Here is proposed language to amend the Aggregate Reporting draft.
> >
> > 1) Replace section 2.1.2 with this:
> >
> > DMARC Aggregate Reporting provides information needed for domain owners
> to
> > ensure that their messages originate with SPF PASS for the
> RFC5321.MailFrom
> > domain and aligned DKIM PASS for the RFC5321.From domain.
>
>
> Section 2.1.2's title is *DKIM Signatures in Aggregate Report*.  Are you
> proposing to change its title?  Otherwise why a generic sentence about SPF?
>
> I wouldn't say that a message /originates/ with SPF PASS.  An spf=pass
> result
> will only be obtained on reception.  Messages originate at MUAs and may be
> revamped at MSAs.  Neither of those has to have an IP registered at the
> domain's SPF record.  SPF IPs are those of the boundary servers.
>
>
> > As a side effect, Aggregate Reporting also provides information about
> servers
> > that choose to deliver messages which are not authenticated by the
> domain
> > owner's DMARC policy.  DMARC is not designed to determine the motivation
> behind
> > a server which delivers unauthenticated messages.
>
>
> Allowing domain holders to have insight into which IP addresses are
> sending on
> their behalf is not a side effect, it is the primary focus of DMARC
> reporting.
>
> There is a field in aggregate reports which states the reason why the
> domain's
> policy was overridden.  And it is there by design.
>
>
> > Consequently, only aligned identifiers are relevant for Aggregate
> Reporting,
> > in the same way that only aligned identifiers are relevant for
> determining a
> > DMARC result.
>
> How you derive that consequence is obscure to me.  Any identifier,
> especially
> if authenticated, is relevant.
>
>
> > DMARCbis allows non-aligned identifiers to be included in report rows,
> for
> > compatibility with RFC 7489, but the practice is deprecated.
>
> Disagreed.
>
>
> > DMARCbis seeks to maximize reporting participation by minimizing the
> processing
> > burden placed on evaluators during both message evaluation and report
> > generation.  A specific design goal is to require only that
> evaluation-time
> > processing which is required to determine a result for the SPF and DKIM
> > components, both of which MUST be evaluated for each reported message.
>
>
> Evaluating DKIM signatures is indeed a burden, especially if using long
> keys.
> The cost of adding an evaluated identifier to a report, in comparison, is
> totally negligible.  Nobody is going to evaluate a signature at report
> generation time, because the message might have been deleted and/or DKIM
> keys
> revoked after some hours.  The only issue is how to store and retrieve the
> results.  That's how the content of aggregate reports is determined.
>
> Considerations on what to evaluate don't belong to aggregate reporting
> spec.
>
>
> > DMARCbis requires only one aligned DKIM identifier to be reported per
> message.
>
>
> Disagreed.
>
>
> > When the aligned DKIM result is PASS, the identifier which generated the
> > PASS result is reported.   When all aligned DKIM identifiers produce
> FAIL, the
> > aligned signature which is closest to the top of the message should be
> chosen,
> > because it is most likely the last one applied and therefore the one
> least
> > likely to be superceded.   Additional aligned identifiers MAY be
> reported at
> > the discretion of the evaluator.
>
>
> As long as aggregate reporting also serves to convey an insight on abuse,
> authenticated identifiers have some relevance.  Reporting failed
> identifiers
> serves to direct domain owners to fix their signing practices, and is only
> relevant during the initial period of deploying the signing software.
>
>
> > By reporting on the most important DKIM identifier only, aggregation
> levels are
> > increased, report generation complexity is reduced, and report sizes
> will be
> > reduced.   Smaller reports lower the bandwidth burden for message
> transmission
> > and reduce the need to fragment reports into multiple messages.
>
>
> I don't think this leads to significant savings.  My understanding is that
> the
> size limiting suffix of the rua= URI was stroked because reports exceeding
> the
> commonly accepted 10Mb size have not been observed.  That is to say,
> fragmentation doesn't seem to be an issue.
>
>
> > Because an excessive number of signatures might be used as an attack
> method,
> > evaluators are cautioned to limit the maximum number of DKIM signatures
> that
> > they evaluate.
>
>
> Agreed, but this statement doesn't belong to aggregate report spec.
>
>
> > For similar reasons, and to ensure interoperability between report
> > generators and report receivers, report generators that provide more than
> > the one required DKIM result, must limit results to a maximum of 10
> > concurrent DKIM signatures.
>
> I don't recall a report with more than 10 signatures, but if it arrived it
> couldn't cause any DoS nor any interoperability issue.
>
>
> > 2) Change the XML schema to limit the maximum number of DKIM results:
> >
> > <xs:complexType name="AuthResultType">
> >    <xs:sequence>
> >      <!-- There may be no DKIM signatures, or multiple DKIM
> >           signatures. -->
> >      <xs:element name="dkim" type="DKIMAuthResultType"
> >                  minOccurs="0" maxOccurs="10"/>
> >      <!-- There will always be at least one SPF result. -->
> >      <xs:element name="spf" type="SPFAuthResultType" minOccurs="1"
> >                  maxOccurs="unbounded"/>
> >    </xs:sequence>
> > </xs:complexType>
>
>
> I see no reason to put such a limit.
>
>
>
> Best
> Ale
> --
>
>
>
>
>
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>