[dmarc-ietf] Add MLS/MLM subscription/submissions controls to DMARCbis

Hector Santos <hsantos@isdg.net> Mon, 01 May 2023 00:05 UTC

Return-Path: <hsantos@isdg.net>
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 15217C151532 for <dmarc@ietfa.amsl.com>; Sun, 30 Apr 2023 17:05:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=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=pass (1024-bit key) header.d=isdg.net header.b="JYKftbr0"; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b="Wt6ZSvOF"
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 dbR3t5Fus7PU for <dmarc@ietfa.amsl.com>; Sun, 30 Apr 2023 17:05:16 -0700 (PDT)
Received: from mail.winserver.com (mail.winserver.com [3.137.120.140]) (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 78DAEC14CF0C for <dmarc@ietf.org>; Sun, 30 Apr 2023 17:05:16 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha256; c=simple/relaxed; l=8914; t=1682899508; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:From:Message-Id:Subject: Date:To:Organization:List-ID; bh=D+CV+QCjxTYamZupjixkPK4tsS1T9ap ohsJc3A+0fco=; b=JYKftbr0ejBZAjQnOtVZmb+ByV5iE28vafeh+h3nLQPEcoW qLfeV6v1BOfwx7YrDJr2j1NwvAPEyfdAj/+dEkWrTENQjv/sN5VmjZl9tJWl4DTM H8prmHa9/VqiCfW39ujWSEVODDEajNvfaP0A8OmBCmAA8gAVBS8FWWhyZdp0=
Received: by winserver.com (Wildcat! SMTP Router v8.0.454.13) for dmarc@ietf.org; Sun, 30 Apr 2023 20:05:08 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=none author.d=isdg.net signer.d=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer);
Received: from beta.winserver.com ([3.132.92.116]) by winserver.com (Wildcat! SMTP v8.0.454.13) with ESMTP id 3292279176.1.6792; Sun, 30 Apr 2023 20:05:06 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=8914; t=1682899503; h=Received:Received:From: Message-Id:Subject:Date:To:Organization:List-ID; bh=D+CV+QCjxTYa mZupjixkPK4tsS1T9apohsJc3A+0fco=; b=Wt6ZSvOFC0zTRknYd2PDmbRQNyoI zT2ZL/cXznRN12JcdjQEVhcNOQhtbMxCc+gFfYmNctVnV6DR1pimhNQWFxw+E6zn Rda51NH2Abfl1t1MXYyjiVEeEbthE3w7bBdQCy2+Jjy93jw2vVSbtbnO3Fqv/KWp yLcPR7O/wEKTkjw=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.12) for dmarc@ietf.org; Sun, 30 Apr 2023 20:05:03 -0400
Received: from smtpclient.apple ([99.122.210.89]) by beta.winserver.com (Wildcat! SMTP v8.0.454.12) with ESMTP id 3738316801.1.3404; Sun, 30 Apr 2023 20:05:01 -0400
From: Hector Santos <hsantos@isdg.net>
Message-Id: <B4E79EF6-E5F5-4969-824A-329576ECF20C@isdg.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_578749AE-4343-4FD8-B8D2-1F8CE20F7C71"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\))
Date: Sun, 30 Apr 2023 20:04:50 -0400
In-Reply-To: <CAH48ZfzmQJBb3xNSvVn84wpwf5SK2F0RSNQnSNObtxKfdHaY1w@mail.gmail.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
To: Douglas Foster <dougfoster.emailstandards@gmail.com>
References: <CALaySJ+NBg9vzqa0_t-sBf7EKXQ3A=DTyy-Vc7M-ZK9-vfJxmw@mail.gmail.com> <29216533.CRhL9lMF2B@localhost> <3141092.K83ThNGNZP@zini-1880> <CAH48ZfzS+MCC4-Dk3mZhF_bwc9hzWowApgPG3am14bjB9ZDz3Q@mail.gmail.com> <630A8A65-E04D-4C48-AE80-516F610EB93A@isdg.net> <CAH48ZfzmQJBb3xNSvVn84wpwf5SK2F0RSNQnSNObtxKfdHaY1w@mail.gmail.com>
X-Mailer: Apple Mail (2.3731.400.51.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/NdEJyCx1iY9AqYYugNcvI0k5Mj4>
Subject: [dmarc-ietf] Add MLS/MLM subscription/submissions controls to DMARCbis
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: Mon, 01 May 2023 00:05:21 -0000


> On Apr 29, 2023, at 4:42 PM, Douglas Foster <dougfoster.emailstandards@gmail.com> wrote:
> 
> ...
> 
> But I need to clarify whether I understand your point.   What I am hearing is:
> For the short term, mailing lists should refuse postings from DMARC-enforcing domains.   That position can be relaxed only if all participating domains have agreed to ignore DMARC Fail for messages from the list  (Ale floated some ideas about that approach.)
> For the longer term, we need a non-DKIM method for delegating rights to a third party.

Ideally, the goal is to eliminate “From Rewrite” to return to the “good ol’ days.”  So the first time is to recognize having subscription and submissions controls is a natural consideration for the DKIM Policy "Protocol Complete” model. If the MLS supports the protocol, it would consider this method more so than a destruction method that tear down security.  This will also pass the buck back to the domain owner to deal with its user’s needs or not.

> You talk about "incomplete protocol" as if this is a commonly understood and accepted term.  I interpret it to mean a third-party authentication method other than DKIM.  DKIM does serve for third-party authentication where it has been embraced and deployed.   So the issue is that it has not been practical for many situations and we do need another option.

Protocol complete is a client/server protocol negotiation concept.  It basically means the “State Machine”, the conversation between the client and server is well-defined. No Loop Holes!!!! Very key concept in protocol design.

In terms of DKIM Signing Practices, you can read "Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol https://www.rfc-editor.org/rfc/rfc5016.txt <https://www.rfc-editor.org/rfc/rfc5016.txt> for its definition.

	DKIM Signing Complete: a practice where the dtomain holder assert
        that all legitimate mail will be sent with a valid first party signature.

But I believe it is not Protocol Complete and to achieve this with DKIM Policy Modeling, you have to cover the other signing scenarios which includes 3rd party signing scenarios. 

ATPS is the best we got and it works.  You don’t have to worry,  You are using gmail.com <http://gmail.com/>. Relaxed policy. Minimal security.  ietf.org <http://ietf.org/> Rewrite destroys my isdg.net <http://isdg.net/> domain security even though I have ietf.org <http://ietf.org/> authorized as an ATPS signer.  

It should honor policy and reject my submissions.   Idea.  Add the option to the subscription. If you don’t care, let it rewrite to join or use another unsecured address.

Not hard.

—
HLS