Re: [dmarc-ietf] PSD Related Privacy Considerations For Aggregate Reporting Draft

Douglas Foster <dougfoster.emailstandards@gmail.com> Thu, 09 February 2023 14:01 UTC

Return-Path: <dougfoster.emailstandards@gmail.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 28994C16B5BC for <dmarc@ietfa.amsl.com>; Thu, 9 Feb 2023 06:01:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6Yl_3AjXga3 for <dmarc@ietfa.amsl.com>; Thu, 9 Feb 2023 06:01:54 -0800 (PST)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C1CBC1782B1 for <dmarc@ietf.org>; Thu, 9 Feb 2023 06:01:25 -0800 (PST)
Received: by mail-lj1-x22a.google.com with SMTP id y19so2137845ljq.7 for <dmarc@ietf.org>; Thu, 09 Feb 2023 06:01:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RuqyO5bhEhVh30d//ODVs42YvWcNp++0UENLZuLzBWo=; b=fKqs7aWvO6bgDBGLRaRRFcvANVs8aosXxxhX16YmpKgEBaZBjqEzxM/hevxFNW7J08 AIJ6xJlpkuMfEKYgHX03zTi/v+93SQkoHXGWc0rdTQ1AcX/JNYOUuMTa8HMaaUWIOnYW j7O8RCJERSPi+KomIrFwWv9nWRcK5Msyw8pPY30njLctD8esIeTCobBW8/g7cLJDnT1D Mitd4GnRocY7K0Fp1QrU06ayP2k4p+Kfq6f7q8wAoOXrbnwMuP2WtA64ajCLJi3vtmAn LZs452pLvGLAeCLaOZNxfEoMmp8b3SfNYQ72NTYXT9We5h+5RC4KV+iAZLeW+8QnTGxb kccA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=RuqyO5bhEhVh30d//ODVs42YvWcNp++0UENLZuLzBWo=; b=4yvwtQblkwvtQdfj878uzWZNw1GP/B89HEvaODT2VQxi0Txi5o/jmBVJodijdC4/ez KmfN5awQkq3ZBQ41YeN6L9sL1yYBv6OLizzveDeSGjtau8ehycvCJYPTh62e6RNOkocD 6qLkTdIxXH/fYTgW8WETiRii/S/8YH8lhWhvUMjhTwtFY5ajAxid9ZWjai/3RYpNL5ic faD+uqwn4j9+5Nau2UHw/aZCwvDV05Y/gbJrniFEB9rAiQIFsUDlRD1i+W5iMX+tF2fB 5oFa2TAM/7jGHxC6ox0FM9au6RliYNBHEMsmq4EymgNNRzb+pJbZRDEQ79jIrJs6wXg1 mU3A==
X-Gm-Message-State: AO0yUKV+40DkNTYGG7unRZvk00s5bQccNQQsSZIeoVOptRImyero28H3 LPJxAay8H5PryaEnHN59SJRsiKtrZBU0duv/hPcy59rQKfM=
X-Google-Smtp-Source: AK7set/ZlCGCh+98cxrdhSrsMkj/efVDmRAMSLd8kEdOvbqRgU1A2v+iwABUWx1r40loOAE7PfUQv/KMbFuVTZJTF4o=
X-Received: by 2002:a2e:151c:0:b0:293:3418:2fcc with SMTP id s28-20020a2e151c000000b0029334182fccmr215358ljd.36.1675951283422; Thu, 09 Feb 2023 06:01:23 -0800 (PST)
MIME-Version: 1.0
References: <11529029.Y877iPkkNG@zini-1880> <MN2PR11MB43510C0C3C2B94846144F102F7EA9@MN2PR11MB4351.namprd11.prod.outlook.com> <CABZJ8k=Rkh9+AoDA+N2tawU+GkizNRS-MG14sRayYHWBmFP62A@mail.gmail.com> <CAH48Zfy8eqoXhqEZCe8GGSDvTccYiBi0ETipfWRMvNuTEqy-_w@mail.gmail.com> <CAHej_8=mDe15Soyt-VN7Sb_==8ggXQPJ=8a9vkdC1-PYJS-PWg@mail.gmail.com> <CAH48ZfxKY7ZPo0K=SBQxr1frMPvijjR1wuw+xGZ7wbjNjvYZrg@mail.gmail.com> <CAH48Zfyn0gckyrjwmSjF_hMMVhJuCK0ipWq=7pUVzmwzRSfS9w@mail.gmail.com> <CAHej_8nZnFdM04Ss6kN+9BkGbB2gnLC4jn69xBKkoJv6Khk_Qw@mail.gmail.com> <CAH48Zfxz9vbGYhfM-23F+EyYwxpLJbrNy3xZ+ug-C8yyCE37cw@mail.gmail.com> <CAHej_8krE0atAx8-_cVqgm6LrVcuXyRyFctcwUOLdOCc_p-ajA@mail.gmail.com>
In-Reply-To: <CAHej_8krE0atAx8-_cVqgm6LrVcuXyRyFctcwUOLdOCc_p-ajA@mail.gmail.com>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Thu, 09 Feb 2023 09:01:13 -0500
Message-ID: <CAH48Zfx9mJvGYVkjAzc7=09Mc9BxfY31e6x55r3bvGm8tTwhQQ@mail.gmail.com>
To: Todd Herr <todd.herr=40valimail.com@dmarc.ietf.org>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e8c7b105f444d015"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/5unaSyfPNJp-y2ZdEfSGBpR8Tw8>
Subject: Re: [dmarc-ietf] PSD Related Privacy Considerations For Aggregate Reporting Draft
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 09 Feb 2023 14:01:58 -0000

Consider the limited usefulness of SP=NONE, NP=REJECT, when applied to
these email addresses:

user@members.example.com   (subdomain used for mail)
user@www.example.com (host name used for web, not a valid domain for mail)
user@mx.example.com (host name used for mx, not a valid domain for mail)
user@_domainkey.example.com (DNS node used for TXT records, not a valid
domain for mail)
user@autodiscover.example.com (host name used for connecting mail user
agents, not a valid domain for mail)
user@bigdeals.example.com (non-existent domain name, not used for any
purpose)

NP=REJECT only protects the last entry.   An attacker who wants( to use a
fake domain can get around the NP clause simply by choosing a name that
does exist in DNS. My examples are intended to suggest the ease of finding
names that will not be blocked by the NP clause.

The combination of SP=NONE, NP=REJECT implies that the domain owner knows
all of his mail-sending subdomains.   When this assumption holds, the much
better defense is to configure DMARC policies with p=policy on the domains
that send mail, and SP=REJECT on the organization domain.   This defense
ensures that any domain which lacks a DMARC policy will be rejected.   in
this example, members.example.com becomes the only domain with policy NONE,
via p=NONE on members.example.com.  All of the others are blocked by
SP=REJECT.   This approach also allows P=REJECT on selected subdomains,
while allowing P=NONE on subdomains that are used with mailing lists.

A domain owner who is serious about blocking bogus domain names should
absolutely use the latter approach.   Non-mail domains will never be used
for legitimate impersonation or mailing lists, so it becomes a minimal
configuration for any domain owner that has control of all of his
mail-sending domain names.

In sum, I expect spammers to use non-mail domains rarely if ever, and even
if they do, NP=REJECT is unlikely to expose the attack.   Overall, it is
false security.

To be clear, all of the above relates only to subdomains of a registered
organization only.  NXDOMAIN on an organization domain should be blocked,
and the work of the DMARC for PSD project was based on evidence that
attackers do attack using non-existent organizations.

Doug Foster

On Tue, Feb 7, 2023 at 8:51 AM Todd Herr <todd.herr=
40valimail.com@dmarc.ietf.org> wrote:

> On Mon, Feb 6, 2023 at 9:25 PM Douglas Foster <
> dougfoster.emailstandards@gmail.com> wrote:
>
>> You actually summarize my points pretty well.  Here are the three
>> concepts:
>>
>> 1) People send mail with non-existent RFC5322.From domains (subdomains of
>> existent domains)  all the time, and that mail is wanted.
>>
>> Yes, that is my assertion based on research into my mail stream.   I
>> spent several months checking every From address for NXDomain, MX Exists,
>> or A Exists.   I found that none of these tests added any value; it was
>> mostly an exercise for the benefit of this issue and this group.   After a
>> while, I stopped checking to reduce overhead.   This is an assertion of
>> fact, which I have presented several times.   Every mail stream is
>> different, so maybe someone else can present different data.   But oddly,
>> no one has presented other data, which makes me wonder if no one else can.
>>
>> Anyone can prove me wrong with more comprehensive data, or you can accept
>> my results on blind faith, but you should not write text based on untested
>> assumptions, when actual data will answer the question.
>>
>> 2) The NP=reject tag is useful when PSD=Y, when applied to the PSD+1
>> organizational domain only.
>>
>> Every organizatioin MUST be registered.  Mail coming from an unregistered
>> organization should be rejected.
>>
>> However, when a PSD's NP clause is applied to non-existent subdomains of
>> an existent organization that has no DMARC record, the use is
>> inappropriate.   Based on #1, it is not only inappropriate but also likely
>> to be wrong.  With this limitation, PSD policies should always publish
>> NP=reject.
>>
>> 3) The NP tag may be of interest to some organizations.
>>
>> Whether NP on organization policies is useful or not will depend on
>> whether it is applied correctly or not.   My expectation is that some
>> organizations will publish NP=reject when they should not, causing false
>> positives.   I also expect that some organizations will publish NP=reject
>> correctly, and the test will never fail because spammers are very unlikely
>> to send using non-existent subdomains of registered domains.
>>
>> Assuming that there are exceptions to everything, perhaps someone can
>> find some messsages that fits these characteristics.  If so, we have to
>> look at the signal-to-noise ratio between correctly blocked messages and
>> incorrectly blocked messages.   If the ratio is wrong, evaluators will
>> disable the test anyway.
>>
>> Finally, I don't have any problem with the definition of non-existent.
>>  A domain or subdomain is non-existent if it returns NXDOMAIN.   If the
>> organization domain does not exist, any messages that use that domain
>> should be blocked.   If the organization domain does exist, I am
>> unconcerned whether a particular subdomain exists.   If someone wants to
>> convince me that I should be concerned, I need data.
>>
>>
> It's not clear to me that your understanding of the np tag matches mine,
> so I'm going to ask a clarifying question or two.
>
> Do you believe that a DMARC policy record containing the tag "np=reject"
> means:
>
>    1. If the RFC5322.From domain (which is necessarily a sub-domain of
>    the domain publishing the policy record) does not exist, then reject the
>    message, OR
>    2. If the RFC5322.From domain (which is necessarily a sub-domain of
>    the domain publishing the policy record) does not exist AND the message
>    does not pass DMARC validation checks, then reject the message
>
> The current text for DMARCbis describes the np tag as choice 2 here, and
> so I don't understand your contention that "some organizations will publish
> NP=reject when they should not, causing false positives", because even a
> domain so careless (in my opinion) as to permit mail to be emitted using
> non-existent sub-domains while still publishing a DMARC policy record
> should have things configured to ensure that such mail will pass DMARC
> validation checks. A message using a non-existent From domain that also
> fails DMARC validation checks where a prevailing DMARC policy exists seems
> to me to be the epitome of unauthorized mail, so I don't see how rejecting
> it would be a false positive. Can you help me understand why rejecting such
> a message would be the wrong thing to do?
>
> --
>
> *Todd Herr * | Technical Director, Standards and Ecosystem
> *e:* todd.herr@valimail.com
> *m:* 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
>