On Sun 27/Aug/2023 20:49:26 +0200 Douglas Foster wrote:
I am much discouraged by the recent discussion about false DMARC PASS
based on false SPF PASS or malicious mDKIM replay. When combined with the
discussion about false DMARC FAIL for mailing lists, it seems like we have
a very unimpressive standards proposal.
We have proposed defending against false SPF PASS by providing a DMARC
option for “DKIM-only”. This will provide a solution to the domain owner’s
problem, at least for those evaluators who understand and enforce the
DKIM-only parameter. But it does not come close to solving the
Evaluator’s problem, because the Evaluator is at risk of deception from
impersonation of any hosting service’s client domain.
Consider the close similarity between these two scenarios:
Legitimate Client via Legitimate Domain
· MailFrom = user@GoodDomain, From=user@GoodDomain, Rcpt
To=user@TargetDomain
· Received #1: From clientdevce.tld by inbound.hostingservice.tld with
SMTP (Authenticated)
· (Normal routing)
· MailFrom = user@GoodDomain, Rcpt To=user@TargetDomain
· Received #2: From outbound.hostingservice.tld by inbound.TargetDomain
with SMTP (Unauthenticated)
· Result: SPF PASS and DKIM PASS based on SPF Strict Alignment
Attacking client via Co-Conspirator domain
· MailFrom = user@GoodDomain, From=user@GoodDomain, Rcpt
To=user@ConspiratorDomain
· Received #1: From maliciousserver by inbound.hostingservice.tld with
SMTP (Unauthenticated0
· (SPF Failure intentionally ignored. Forwarding without any change
to MailFrom)
· MailFrom = user@GoodDomain, Rcpt To=user@TargetDomain
· Received #2: From outbound.hostingservice.tld by inbound.TargetDomain
with SMTP (unauthenticated)
· Result: SPF PASS and DKIM PASS based on SPF Strict Alignment
IMHO hostingservice.tld is overly sloppy at allowing and signing fake From:
values. Doing so is legal, but they should be considered responsible for the
consequences.
Note that these two scenarios are nearly identical to the evaluator at
TargetDomain. To distinguish between the two scenarios, the evaluator
needs to reliably know either:
· that the legitimate client used authenticated SMTP, which seems
infeasible, or
This is not unfeasible. It's useless. I do add an "Authentication-Results:
tana.it; auth=pass (details omitted)", in this message too. I omit the
logged-in userID 1) to avoid feeding the trolls and 2) because it may well
differ from From:. Anyway, these A-R are to be discarded on entering a new
domain's MX.
· that the Rcpt To address was altered in transit.
This is unfeasible, see below.
Authentication result headers are only useful if the Evaluator knows that
the results apply to an unauthenticated connection, which in these examples
is uncertain in respect to the Received #1 header. Additionally,
authentication result headers do not document the SMTP Rcpt To address.
In general, A-R by inbound.hostingservice.tld is discarded by TargetDomain.
We have only one tool for downstream communication of the Rcpt To address:
the “For” clause of the Received header. Some servers also document the
current value of the Mail From address by including a Received comment of
(envelope-from <emailaddress>). Our solution needs to take advantage of
this capability. If hosting services will add these clauses to inbound and
outbound Received headers, downstream evaluators could parse the headers to
distinguish between the malicious message and the legitimate one. Even
better, the hosting service itself could use the inbound and outbound Mail
From data to detect the malicious impersonation and block the message.
The Received header information will have added credibility if both inbound
and outbound Received headers are included in a DKIM signature provided by
the hosting service.
Now DKIM informally discourages to sign trace fields, and we are not going to
change that. However, "Include the SMTP RCPT-TO address in the DKIM signature"
is one of the potential solutions to the replay attack, where another solution
similarly proposes to specify destination domains.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
