Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

Alessandro Vesely <vesely@tana.it> Sat, 26 September 2020 10:31 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 495763A1214 for <dmarc@ietfa.amsl.com>; Sat, 26 Sep 2020 03:31:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Level:
X-Spam-Status: No, score=-2.121 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 gnmPmcAS-HuK for <dmarc@ietfa.amsl.com>; Sat, 26 Sep 2020 03:31:47 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52EAB3A1213 for <dmarc@ietf.org>; Sat, 26 Sep 2020 03:31:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1601116302; bh=Wba+25INj0ykZMGUcCdu5rD11DSyy+yLT/8xNvCgAfU=; l=2180; h=To:References:From:Date:In-Reply-To; b=CZWKFn2MGvvqzCWEMomdn+QEdU2yMYiau1Y5m5mmVagtLZFh0XLiqcHTubMFMXx2/ Vwh6Cq+0kvlML84p0J2266AibeWCyRhDPOox26D84VnfF3YolACHaKMPe8VRxxfDaR BxHWBFhuJX/HpMI2mGJf9ZaIkG2bgY6MCi4Q4ZwZ/9ucfoodVw/9Y84kfFl4z
Authentication-Results: tana.it; auth=pass (details omitted)
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 00000000005DC09F.000000005F6F188D.00002933; Sat, 26 Sep 2020 12:31:41 +0200
To: dmarc@ietf.org
References: <20200815225306.967CC1E9E41D@ary.local> <6089649.VB6F1bvo3X@zini-1880> <159dc0da-0f34-fa71-e20f-89135f14182e@dcrocker.net> <6484002.GchzCIbhPQ@zini-1880> <aa8eb7e5-e16f-e99d-2164-5654ed0024dd@dcrocker.net>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <af165f28-fab7-c339-1808-4c14e21631b4@tana.it>
Date: Sat, 26 Sep 2020 12:31:41 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <aa8eb7e5-e16f-e99d-2164-5654ed0024dd@dcrocker.net>
Content-Type: text/plain; charset="us-ascii"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/q0p1eaIF3s8bnbDIrUkZhsxM0Ek>
Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
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: Sat, 26 Sep 2020 10:31:49 -0000

On Sat 26/Sep/2020 05:03:51 +0200 Dave Crocker wrote:
> On 9/25/2020 4:21 PM, Scott Kitterman wrote:
> 
> Well, ok, here's one that shows lack of efficacy, and it's a big one: EV-certs
> 
> /Google to bury indicator for Extended Validation certs in Chrome because users 
> barely took notice/
> 
> https://www.theregister.com/2019/08/12/google_chrome_extended_validation_certificates/ 
> 
> 
> "The reason is simple. "Through our own research as well as a survey of prior 
> academic work, the Chrome Security UX team has determined that the EV UI does 
> not protect users as intended... users do not appear to make secure choice..."


A pointer to a better aimed report circulated on this list:
*End-to-End Measurements of Email Spoofing Attacks*
https://www.usenix.org/conference/usenixsecurity18/presentation/hu

They say:

    Our phishing experiment shows that security indicators
    have a positive impact on reducing risky user actions,
    but cannot eliminate the risk.


>> If this is just an input into an algorithm, then your assertion that you are
>> only providing another input is supportable, but that's contrary to the DMARC
>> design.
> 
> Perhaps you have not noticed but the demonstrated field use of DMARC, to date, 
> tends to be contrary to the design, to the extent anyone thinks that the design 
> carries a mandate that receivers follow the directives of the domain owners.


Some organizations are very careful at setting DMARC policies.  Paypal is a classic example, as they don't allow protected transactional domains to be casually used by humans.  Such organizations need to be able to explicitly opt out of the Sender experiment.  Other organizations may want to opt in, possibly allowing a limited class of mediators.

The real word bond is something along the lines of /I tell you how to discard phishing, how you protect your users is up to you/.  Some receivers focus more on MTA filtering, other focus on security indicators.  Both actions depend on the DMARC policy published at the From: domain.  If the From: domain participates in the Sender experiment, then the policy at Sender: may be relevant as well.


Best
Ale
--