I used authentication results in the general sense, to include ARC sets, Authentication-Resilts, and Received-SPF. ARC is most applicable to this situation but the others are not consistently removed prior to message crossing organization boundaries.
After writing this, I wondered if the best approach would be the CVE/CCE process, since it should be the hosting services problem to prevent. Are you suggesting that this concern is already well handled in the hosting industry? I thought this threat was the reason that we are creating a DKIM-only option for DMARCbis, and therefore it was not well handled. Doug On Mon, Aug 28, 2023, 5:21 AM Alessandro Vesely <[email protected]> wrote: > 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 >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
