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

Alessandro Vesely <vesely@tana.it> Tue, 26 April 2022 08:07 UTC

Return-Path: <vesely@tana.it>
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 36491C1D2DBB for <dmarc@ietfa.amsl.com>; Tue, 26 Apr 2022 01:07:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.051
X-Spam-Level:
X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.857, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=tana.it header.b=Dvs80uVP; dkim=pass (1152-bit key) header.d=tana.it header.b=BmmmEDor
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 RNUA6bY_aM7B for <dmarc@ietfa.amsl.com>; Tue, 26 Apr 2022 01:07:06 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD8F1C3A9195 for <dmarc@ietf.org>; Tue, 26 Apr 2022 01:06:58 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1650960411; bh=pTELZaHSnzDz4kFNFY+SlDetH7x+KRleDqxJu7V/a1k=; h=Date:Subject:To:References:From:In-Reply-To; b=Dvs80uVPRIU/7DceiJdAK13D2FiS/A/5PQ4cleh/yep2mG/rvH30bnTO1a+u4sX8Y qqyqJpD5GIGhCZjBzmsBA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1650960411; bh=pTELZaHSnzDz4kFNFY+SlDetH7x+KRleDqxJu7V/a1k=; h=Date:To:References:From:In-Reply-To; b=BmmmEDorr7DqQH6p8Cg1M1ys8AzcWGCdSC+m+iarzevXqfa2qwtyMKVUPlntJFLdg liWMDBv/dlFU9ppPsWT0tGiTasE+ws2jlecn/eWksJGVl+Uv9jvJOR/MUb2O8GwbaB XU4mk+OUODkGleCrdGxeBu55bH2m9ApwAzcolPdP82fzy1YYPy7kvgaMguVPU
Author: Alessandro Vesely <vesely@tana.it>
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0D6.000000006267A81B.000077F6; Tue, 26 Apr 2022 10:06:51 +0200
Message-ID: <83b5228b-adca-3a5d-3056-3ec5befa634b@tana.it>
Date: Tue, 26 Apr 2022 10:06:50 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0
Content-Language: en-US
To: dmarc@ietf.org
References: <CAH48Zfz5MWDuQa1DJQE_YK9gAUL4P-se4CeGAGYCf+c6D0ysaA@mail.gmail.com> <2934216.d6BrxOLGqM@zini-1880>
Authentication-Results: tana.it; auth=pass (details omitted)
From: Alessandro Vesely <vesely@tana.it>
In-Reply-To: <2934216.d6BrxOLGqM@zini-1880>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/Doe6-IobSmnbm4400wP17WUxCII>
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: Tue, 26 Apr 2022 08:07:13 -0000

On Mon 25/Apr/2022 05:56:46 +0200 Scott Kitterman wrote:
> 
> 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.


I object that this text undermines the robustness of the protocol and may sound 
like a campaign for strict alignment.  Relaxed alignment is safer from a 
flexibility POV, as it accounts for occasional @hostname.example.com.  It has 
played a relevant role in DMARC success, and it's not by chance the default.

Here's an alternative text:

     DMARC evaluation for relaxed alignment is sensitive to errors in the
     determination of the organizational domain due to erroneous DNS settings by
     either the organizational domain or its PSD parent.  If the PSD parent is
     incorrectly selected as organizational domain, then relaxed alignment can
     potentially allow a malicious sender to obtain DMARC PASS while
     impersonating the relevant organization.  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.


    or by publishing psd=n.


> 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.


The latter alternative is obviously easier than monitoring the DNS settings of 
the PSD parent, and has to be carried out anyway in case.


Best
Ale
--