Re: [dmarc-ietf] Comment on DMARCbis, was draft-ietf-dmarc-psd

Alessandro Vesely <vesely@tana.it> Thu, 06 February 2020 18:44 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 8CC231201EA for <dmarc@ietfa.amsl.com>; Thu, 6 Feb 2020 10:44:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.298
X-Spam-Level:
X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 qLy6cW_I6Ye7 for <dmarc@ietfa.amsl.com>; Thu, 6 Feb 2020 10:44:36 -0800 (PST)
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 002971200B2 for <dmarc@ietf.org>; Thu, 6 Feb 2020 10:44:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1581014673; bh=dsl7et0MR7NaKIfu9E/WzoT5H+vpxiJs1tGYH3xZXO0=; l=3107; h=To:References:From:Date:In-Reply-To; b=CXTRM9rY1nnXGBXxsigIDDPZtFJi4zW6PIR+Ic2wktwtkiJsb+fyuFDeXIIHRz3aZ K4LGZpLs9xCm+Wkq4vU9wslgYvjdqGBjWL67HVdXyhBgWiRhyzPKNp5hJhSS3URdAg 26uigBwB/J7lArqcpFkQNdRTAzJnJpsbrYPxcMKvNHp/sm3jUq0U5hFLNHyoJ
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.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC092.000000005E3C5E90.000034D2; Thu, 06 Feb 2020 19:44:32 +0100
To: dmarc@ietf.org
References: <728d7df1-d563-82f4-bfb3-a65a75fdd662@gmail.com> <2197062.EyKCtXoLNb@l5580> <CAJ4XoYdgHD7O8wzv1J-=qC_M7-r32Z_UxHakTZWbMFOAU5OSjA@mail.gmail.com> <9467613.0cjHueyR6G@l5580> <CAL0qLwb-9OMzp=JAfDKsALEFY0T8zEWg9LOnfQSPNaJcpfL8rw@mail.gmail.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <f1bbfc6b-a20f-5cb0-0e65-aee2c1a32536@tana.it>
Date: Thu, 6 Feb 2020 19:44:32 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <CAL0qLwb-9OMzp=JAfDKsALEFY0T8zEWg9LOnfQSPNaJcpfL8rw@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/bTNUydkyY-DZgvV0C78wyznbLcw>
Subject: Re: [dmarc-ietf] Comment on DMARCbis, was draft-ietf-dmarc-psd
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: Thu, 06 Feb 2020 18:44:38 -0000

On Tue 04/Feb/2020 22:26:30 +0100 Murray S. Kucherawy wrote:
> On Tue, Feb 4, 2020 at 1:20 PM Scott Kitterman <sklist@kitterman.com> wrote:
> 
>> I agree on DMARCbis.  I don't think advancing this draft has a significant
>> effect on that.  Worst case, if DMARCbis is done before we can reach any
>> conclusions about PSD DMARC, then we publish DMARCbis without PSD DMARC in
>> it.


+1, albeit I don't think DMARCbis arrives so quickly


> I think we've always been assuming that PSD DMARC would be input to
> DMARCbis, so we were planning to start the latter but not close it until
> the former was completed.  This is the first time I've seen a different
> suggestion.
> 
> I'd love to hear more opinions about ordering of the work here.  This seems
> like an ideal time to review and update our milestones.


There are quite some issues about DMARC.  Let me mention aggregate report
format first, as this brings out a third thing which can be done in parallel,
namely to publish http://dmarc.org/dmarc-xml/0.2.

Various tweaks have been proposed, I think they're well summarized in
http://bit.ly/dmarc-rpt-schema

For a second issue, consider whether report generators should track policy
changes during the day and, in case, send multiple reports with different
PolicyPublished.  Otherwise, PolicyPublished would be valid for only a part of
the reported rows, presumably the last.  Is that acceptable?

Another case for sending multiple reports at once is on hitting size limits.
Is better to increase sending frequency instead?  How to negotiate sending
frequency between report consumer's ri= and producer's conditions deserves some
discussion.

I'm sure there's a bunch of other issues, and we should start to collect them.


>> I don't see anything about PSD DMARC being inherently on the critical
>> path for DMARCbis.  I suspect the current major obstacle to DMARCbis is
>> that the question of how to take the PSL out of the equation is unsolved,
>> despite one IETF WG that was supposed to be dedicated to the question.>>
>> I don't think not publishing PSD DMARC helps move DMARCbis forward, so I 
>> think it's a false choice.>>
> 
> I think what Dave proposed about PSL separation from DMARC is entirely
> appropriate and pragmatic, and in fact probably easy enough: DMARC is
> changed so that it says the organizational domain is determined using some
> process [currently] external to DMARC, and then a second document explains
> how that process is accomplished using the PSL (and/or PSD, depending on
> when the experiment result comes in).  That's a fairly simple edit overall,
> and is actually probably minor and non-controversial compared to some of
> the other surgery that I believe is in the queue.


+1, let DMARC core define _organizational domain_ by characteristics.  A second
document present a process, possibly demonstrating how the required
characteristics are met.

Scott's I-D already outlines the characteristics of Branded and
Multi-organization PSDs, that the experimental processes are suited for.


Best
Ale
--