Re: [dmarc-ietf] Additions to draft - Security Considerations

Scott Kitterman <sklist@kitterman.com> Mon, 25 April 2022 21:40 UTC

Return-Path: <sklist@kitterman.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 B65E5C3A4B74 for <dmarc@ietfa.amsl.com>; Mon, 25 Apr 2022 14:40:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=Bq5sIq2M; dkim=pass (2048-bit key) header.d=kitterman.com header.b=dL+FKhr9
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 iTl7fi-C894e for <dmarc@ietfa.amsl.com>; Mon, 25 Apr 2022 14:40:56 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 E5BDBC3A440D for <dmarc@ietf.org>; Mon, 25 Apr 2022 14:40:55 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 89520F8022B; Mon, 25 Apr 2022 17:40:54 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1650922854; h=date : from : to : subject : in-reply-to : references : message-id : mime-version : content-type : content-transfer-encoding : from; bh=Kwe/dZIp0W+RiCqcUtVDdZK+i8EHukYgNL2VRzVNlE4=; b=Bq5sIq2MCtSeTSgKLs/HBltDItMw7NVKbqi4CgQ9onlnVIjsyz3fZEUY+DjKDlRg17QV0 tFGEEZsxDUNHzhbBg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1650922854; h=date : from : to : subject : in-reply-to : references : message-id : mime-version : content-type : content-transfer-encoding : from; bh=Kwe/dZIp0W+RiCqcUtVDdZK+i8EHukYgNL2VRzVNlE4=; b=dL+FKhr967BGaiJ76JxdKQvrg6yhLLddfV/T0MIUdM6VWzW1viQEYA8O4FDSgYhOSE098 niNgtAxywFzUAmjZ55LGmUpwtzdeDQ+Aqnc7iT92O5ABiDhejMdl1OU0l+w+aZ1g6DTYmc2 nZyqeFJC3g8uFPQKGp/tJXe6ApQZ8Kmz1QfVqRSRICTOywrLzh/siWD3p9ZKEUIfbpNefSk 6FI78bT2N+Bq0ZMll6tGSvWlO+ycEdqkKWWQLncsp4PQiSQ7Kht7FotFss5HmR3ZoswK11Q BH1CVvCIzrXCPpJe9lvMEHvRPzC1pvSt30haZtIZzLMug8HAEA7cy2Jf5yNg==
Received: from [127.0.0.1] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 44E68F8020E; Mon, 25 Apr 2022 17:40:54 -0400 (EDT)
Date: Mon, 25 Apr 2022 21:40:54 +0000
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
In-Reply-To: <CAH48ZfxeZPgvFh4ifeuqdtk8KxkA=tpjAX4Hi0vGsQzh1TYqsA@mail.gmail.com>
References: <CAH48Zfz5MWDuQa1DJQE_YK9gAUL4P-se4CeGAGYCf+c6D0ysaA@mail.gmail.com> <2934216.d6BrxOLGqM@zini-1880> <CAH48ZfxeZPgvFh4ifeuqdtk8KxkA=tpjAX4Hi0vGsQzh1TYqsA@mail.gmail.com>
Message-ID: <20A925C5-32B2-40D2-A179-8ABF2B9FB14F@kitterman.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/ebgwdVi8FM482XHOH07iNEHkUbI>
Subject: Re: [dmarc-ietf] Additions to draft - Security Considerations
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.34
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 Apr 2022 21:40:59 -0000

I'm not saying it's not an issue, only that it's not a security consideration.

If the org domain is too high in the tree, then there's a potential for an unrelated domain to generate a DMARC pass when they shouldn't be able to.  If the org domain is too low in the tree it may cause DMARC verification errors, but no ability for an unrelated domain to generate a DMARC pass, so no security issues.

Scott K

On April 25, 2022 9:10:47 PM UTC, Douglas Foster <dougfoster.emailstandards@gmail.com> wrote:
>I am pretty content with your text.
>
>I am still see a security vulnerability without something like
>the OrgsBelow token.  DMARC is all about verified data.   Since the tree
>walk can be compromised by omitting psd=n, the selected organization domain
>needs a verification method.   I don't understand why you think it is
>already handled by the existing text.
>
>
>On Sun, Apr 24, 2022 at 11:57 PM Scott Kitterman <sklist@kitterman.com>
>wrote:
>
>> On Sunday, April 24, 2022 9:16:04 PM EDT Douglas Foster wrote:
>> > I have attempted to capture the security-related content of recent
>> > discussions:
>> >
>> > Security Considerations
>> >
>> > Determination of the Organizational Domain
>> >
>> > DMARC evaluation is highly sensitive to errors in the determination of
>> the
>> > organizational domain, as the organizational domain is used for the
>> default
>> > policy (when the RFC5322.From domain does not have a published policy)
>> and
>> > for determining relaxed alignment.
>> >
>> > If an incorrectly selected organizational domain is actually a parent of
>> > the correct organizational domain, then relaxed alignment will allow a
>> > malicious sender to obtain DMARC PASS while impersonating either the
>> parent
>> > domain or sibling domains.
>> >
>> > If an incorrectly selected organizational domain is actually a child of
>> the
>> > correct organizational domain, then relaxed alignment will produce an
>> > incorrect DMARC FAIL when the message is actually authorized by either
>> the
>> > correct organizational domain or siblings of the incorrectly chosen
>> domain.
>> >
>> > When the RFC5322.From domain does not have a policy record, the
>> > organizational domain policy is needed to demonstrate DMARC participation
>> > and to provide the default policy.   In this case, when an incorrect
>> > organizational domain is selected, and it does not contain a DMARC
>> record,
>> > then the domain will be treated as not participating in DMARC and the
>> > domain owner will not receive reports.   If the incorrectly selected
>> domain
>> > does have a DMARC policy, the applied policy may be different from the
>> > domain owner’s intended policy, and reporting will go to whatever
>> > destination is specified by that policy.
>> >
>> > A DNS path may contain a private registration, where a PSO-registered
>> > domain owner makes subtrees of his domain available to independent
>> > organizations.   This behavior complicates DMARC organizational
>> > determination.    Clients of the private registration will have two
>> > organizational domains in its DNS tree, one at the boundary between the
>> > private registration client and its private registrar, and another
>> between
>> > the private registrar and its PSO.  If a private registry is unknown or
>> > undetected during organizational domain selection, then the registrar
>> > organizational domain may be incorrectly selected as the client’s
>> > organizational domain, allowing the client to obtain DMARC PASS while
>> > impersonating the parent domain or sibling domains.
>> >
>> > Reliance on an externally-authored public suffix list, as specified in
>> > RFC7489, creates stability problems for domain owners and evaluators.
>> An
>> > organization may have their DMARC configuration fully deployed and
>> > successfully tested, then suddenly develop unexplained and difficult to
>> > detect problems if the PSL used by evaluators adds an entry which
>> fragments
>> > the domain’s intended organizational boundaries for email.  Even if the
>> > domain owner manages to detect the problem, getting it corrected may be
>> > difficult or impossible.   Since every evaluator operates on an
>> independent
>> > copy of one or another PSL list, updated at intervals determined by the
>> > evaluator, the domain owner has no certainty about when or if a
>> correction
>> > will be replicated to all evaluators.
>> >
>> > Domain owners can minimize the need for determination of an
>> organizational
>> > domain by publishing a DMARC record for each RFC5322.From domain, and
>> > applying a DKIM signature which provides strict alignment.  When this
>> > practice is followed, the organizational domain is only referenced when a
>> > non-mail subdomain is impersonated by a malicious actor.   This
>> > configuration allows the SP clause on all policies to be confidently set
>> to
>> > REJECT.
>>
>> I think you have a reasonable issue in here, but this is not all security
>> considerations.  I also think the point that it's independent of how the
>> organizational domain is determined is appropriate.
>>
>> My assessment is that this is an issue that it is appropriate to document
>> in
>> this text:
>>
>> > > If an incorrectly selected organizational domain is actually a parent
>> of
>> > > the correct organizational domain, then relaxed alignment will allow a
>> > > malicious sender to obtain DMARC PASS while impersonating either the
>> > > parent domain or sibling domains.
>>
>> I think it needs some work though and can be substantially shorter.  The
>> same
>> potential exists for both public and private registrations.
>>
>> Org domain too low in the tree causing an incorrect rejection isn't a
>> security
>> issue though, that's a protocol problem.
>>
>> How about something like this:
>>
>> 9.7 Determination of the Organizational Domain For Relaxed Alignment
>>
>> DMARC evaluation for relaxed alignment is highly sensitive to errors in
>> the
>> determination of the organizational domain if the RFC5322.From domain does
>> not
>> have a published policy.  If an incorrectly selected organizational domain
>> is
>> a parent of the correct organizational domain, then relaxed alignment
>> could
>> potentially allow a malicious sender to obtain DMARC PASS.  This potential
>> exists for both the legacy [RFC 7489] and current [Section 4.8] methods
>> for
>> determining the organizational domain.
>>
>> This issue is completely avoided by use of strict alignment and publishing
>> DMARC records for all domains/sub-domains used as RFC5322.From domain in
>> an
>> organization's email.
>>
>> For cases where strict alignment is not appropriate, this issue can be
>> mitigated by periodically checking the DMARC records, if any, of PSDs
>> above
>> the organization's domains in the DNS tree and (for legacy [RFC 7489]
>> checking
>> that appropriate PSL entries remain present).  If a PSD domain publishes a
>> DMARC record without the appropriate psd=y tag, organizational domain
>> owners
>> can add psd=n to their organizational domain's DMARC record so that the
>> PSD
>> record will not be incorrectly evaluated to be the organizational domain.
>>
>>
>> I think that captures in a more compact form the issue you are (I think
>> rightly) concerned about as well as appropriate advice to protocol users
>> on
>> how to avoid or mitigate the issue.
>>
>> Scott K
>>
>>
>> _______________________________________________
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>