Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

Todd Herr <todd.herr@valimail.com> Mon, 25 January 2021 21:25 UTC

Return-Path: <todd.herr@valimail.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D79B3A18FB for <dmarc@ietfa.amsl.com>; Mon, 25 Jan 2021 13:25:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REJy5Mu2bVnD for <dmarc@ietfa.amsl.com>; Mon, 25 Jan 2021 13:25:32 -0800 (PST)
Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CECED3A18FE for <dmarc@ietf.org>; Mon, 25 Jan 2021 13:25:31 -0800 (PST)
Received: by mail-qt1-x833.google.com with SMTP id c12so10836903qtv.5 for <dmarc@ietf.org>; Mon, 25 Jan 2021 13:25:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bEVyDjuhk3OIdaGXrFxSSpBuZiCHdHg6LXQge4X63ys=; b=b/27zKV6llfh2M+109Kr0RUwgg0w682tF3WUKR2v/WjPC0MZlCxNU0Nu/9REgYY3cU JjtSJUq+yqvmLSqUlK8ji560ij2gX8LTMuVPL9utce0f5MRyUZsILkqiLhPmG3kG24CD BOjqKS0I8yRBgqxkDauwhCeqvRRYbnE8WFiYTGc+BSivxqGUiTSqlWzhwSeRZ60dyM96 WJ24kKCnd5KizaqlHeAJtWAWjWwt+fpKiBkej4MTi+aX/kpTqxl08aENUhRCtdc0zOFm fUYWot3KGnuGgb4j2BhVgcV9RI3IW62Vzjc+s4J4VzVB9/b6sl5UoCJVLUZp6vzCpq6e i4/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bEVyDjuhk3OIdaGXrFxSSpBuZiCHdHg6LXQge4X63ys=; b=NnR61s6mp8vL+aJkqr0q8VKUDwqfgoD/Fa4e4gNrL9mfmdyYv8OmOLZce10alxAVPK jptwLbnrY6+PyNlUU3+SwXTHPCLgX9vb1o1FoBHTKjTqYFtPMzVlsHkYiIREgRCIdM7A ReMD7H9e8OR/+rojBTHZI69POKjgpXU2BKSOxEC8a1YqfxWAIL13CDWzNEUL4Q5IYmat yDne7+KpnuattUOPUXGSbvcWUopnKHKLGhjDTMJnzJjAwy9gPorZ5JewLAvsqXMX8vUg qrqHgjHMOHz2xR5dvM5TI8TuSr9fO+MQRR6YRjAWcQp9RerEEGJAsqkOZHONMGP87k+q 5EPw==
X-Gm-Message-State: AOAM530VjHzlTMIPY9wLIfEHVF1f4qAsiHfeGfxj9orvjlUPDYcc4aE4 hNFz12miLUyEy2i3pyNW7NglEwOA4UoIatP5dYbwRB+Ijxs=
X-Google-Smtp-Source: ABdhPJxBUS1G/JqH1ru2XjKoiLduyr+UjcQiKok0MFv+dG/TKZHhHOS0mesn8lQTumCrUSSKPT8V9awXIlAUth3LNuA=
X-Received: by 2002:ac8:4a82:: with SMTP id l2mr2506138qtq.298.1611609930678; Mon, 25 Jan 2021 13:25:30 -0800 (PST)
MIME-Version: 1.0
References: <20210125195231.E0DE16C13E26@ary.qy> <12abca41-4420-37c7-c903-7decc012027a@mtcc.com> <CAHej_8nr=SOuk0eUR481xMWhQ8JC5fjhHeE64w++Ltf0XM9TQw@mail.gmail.com> <84ffcfcd-d391-4382-6a23-dfe100407476@mtcc.com>
In-Reply-To: <84ffcfcd-d391-4382-6a23-dfe100407476@mtcc.com>
From: Todd Herr <todd.herr@valimail.com>
Date: Mon, 25 Jan 2021 16:25:14 -0500
Message-ID: <CAHej_8=HMV4=emDA8Cdxsq=zdmhJ_WOYU3sd_mN5ugTOOWSXPA@mail.gmail.com>
To: Michael Thomas <mike@mtcc.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006f580e05b9c02d27"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/noUQtbwuDdKGwRrk-N32mMASd0Y>
Subject: Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jan 2021 21:25:35 -0000

On Mon, Jan 25, 2021 at 3:18 PM Michael Thomas <mike@mtcc.com> wrote:

>
> On 1/25/21 12:08 PM, Todd Herr wrote:
>
> On Mon, Jan 25, 2021 at 2:56 PM Michael Thomas <mike@mtcc.com> wrote:
>
>>
>> On 1/25/21 11:52 AM, John Levine wrote:
>> > In article <
>> CAH48ZfwejX1PHO7x1bjJTYyehXZWMuq3jrHFJzAHWfy1jQ+NQg@mail.gmail.com> you
>> write:
>> >> -=-=-=-=-=-
>> >>
>> >> DMARC alignment on the report seems of limited value unless it is
>> aligned
>> >> to the domain being reported. ...
>> > I'm getting the impression that some of us have not looked at any DMARC
>> reports.
>> >
>> > Aggregate reports contain the domain of the reporter, and the domain
>> > of the sender to whom they are sending the report. They do NOT have
>> > the domains to which the messages were sent or where they were
>> > received, which are often different for forwarded or mailing list mail.
>> >
>> > For at least the third time, there is no "domain being reported". When
>> > I get reports from Google or any other multi-tenant mail provider,
>> > they do not say to which of their gazillion hosted domains the mail
>> > was sent. That is not a bug, and it's been like that for a decade.
>> >
>> Sounds like a bug to me and an issue should be opened. Just because it's
>> a 10 year old bug doesn't mean it's not a bug.
>>
>>
> I disagree.
>
> Authentication results should not differ at a given provider based solely
> on the destination domain, so there is no reason to report results
> separately for each destination domain. Further, there's no value to the
> report generators, especially at large sites like Google, to expend the
> resources necessary to generate and send X reports when one will do.
>
> So you're saying I should be free to spoof any domain I want because
> Google might be inconvenienced?
>
>
> I'm not at all following your point here. Let me explain what I'm trying
to say, then perhaps you can explain what you're trying to say in a way
that might make a dent in my seemingly-addled brain, and then we can move
forward.

As a domain owner who publishes a DMARC policy record, a DMARC aggregate
report tells me the results of authentication checks done by a given
reporter for mail claiming to be from my domain during a specified period
of time. These aggregate reports group the information by source IP,
telling me how many messages were seen from a given IP by that reporter,
what the policy evaluation results were, what the header from was, and what
the results of the "pure" authentication checks were.

If I were an owner of a domain of any reasonable size generating
non-trivial amounts of traffic on a daily basis, I would expect that some
of the traffic in a given aggregate report was stuff I'd sent, and some
would be stuff others had sent.

When it comes to a hosting provider, such as Google or any provider hosting
more than one domain, I do not expect that the authentication results
reported by the hosting provider about my domain will differ based on the
domain hosted by that provider to which the traffic was sent. If Google
reported mail from foo.com (my domain), I would expect that all mail I sent
from a given IP would show the same authentication results regardless of
whether it was sent to bar.org, baz.net, someotherdomain.com, whatever
domains Google might be hosting. I would further expect that any mail that
I didn't send would show in the report as failing authentication checks
(assuming I've got my authentication stuff set up correctly) regardless of
what domain it was sent to at Google.

The reasons for these expectations are several:

   1. SPF checks are based on the domain in the RFC5321.MailFrom header, or
   sometimes on the domain in the RFC5321.HELO; the destination domain has
   nothing to do with the success or failure of SPF
   2. DKIM checks are based on the DKIM-Signature header(s) in the message;
   the destination domain for the message has no role in the DKIM validation
   effort, as the public key is published by the signer
   3. DMARC checks are based on the From domain (which publishes the DMARC
   policy) and the results of the SPF and DKIM checks (did either pass, and
   does the domain that passed align with the From domain?). Again,
   destination domain doesn't play a role in the DMARC check

So, based on my understanding of how DMARC works and the information that
an aggregate report contains, I do not see how the lack of the destination
domain in an aggregate report gives one freedom to spoof any domain.

Can you please explain your position that the lack of destination domains
in aggregate reports gives one freedom to spoof any domain, and further can
you please specify which domain(s) in this scenario might be free to be
spoofed?

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.herr@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.