Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

Alessandro Vesely <vesely@tana.it> Fri, 04 June 2021 09:26 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 349E23A308A for <dmarc@ietfa.amsl.com>; Fri, 4 Jun 2021 02:26:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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.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 Gu6YUB__bbEE for <dmarc@ietfa.amsl.com>; Fri, 4 Jun 2021 02:26:46 -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 077BE3A3084 for <dmarc@ietf.org>; Fri, 4 Jun 2021 02:26:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1622798797; bh=/CRtnpEBhhhBSr3h2MMGWA9VKO6TrLmfhPx+EQ2FwfE=; l=3184; h=To:References:From:Date:In-Reply-To; b=Ay9DgYHROIdH5RzfELjIpNfiVmice6+aKTLTsdb4hPSjp9TApVP8Ch/7Y6nRKZkvQ MZHR4BBpsvI8uwTwxxbX0MDVdkrFWw3b6Tiaxy/8L6y1z3ns7rUQ2AzN2uzBHxDTdS Yx8IIHUO+0RrGiJkhqm20F/cfesDGnp0ulo8J6sNcKvqEUuSVaKjasiD0CdP3
Authentication-Results: tana.it; auth=pass (details omitted)
Original-From: 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 00000000005DC028.0000000060B9F1CD.00006346; Fri, 04 Jun 2021 11:26:37 +0200
To: dmarc@ietf.org
References: <MN2PR11MB4351A6C5A477DB006CB6DD72F73C9@MN2PR11MB4351.namprd11.prod.outlook.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <f04b1dfa-2707-a67e-4df8-bf82d637f4f8@tana.it>
Date: Fri, 4 Jun 2021 11:26:36 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <MN2PR11MB4351A6C5A477DB006CB6DD72F73C9@MN2PR11MB4351.namprd11.prod.outlook.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/vZhhd_olhAlW9rcwsGvzoKQsRLw>
Subject: Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested
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: Fri, 04 Jun 2021 09:26:52 -0000

On Thu 03/Jun/2021 14:47:21 +0200 Brotman, Alex wrote:
> 
> During our interim call last week the topic of extensions within the DMARC aggregate report came up.  There was a discussion about how to best introduce these, but also how they might be best used.  I noted three cases that I could see today; ARC, PSD, and BIMI.   And indeed we have tickets relating to the first two.  The original thought was that the aggregate draft would allow a place for extensions, and then additional drafts would define those within the IETF.  When -02 was originally being worked on, there was a thread about how we might like to see this, though not many responses.  The result is in section 4 of the -02 draft [1].


I have some comments about that attempt.  First, it shows extensions right below <feedback>, while it seems more useful to have them as child of <record>.  Second, I'm not sure we need an <extensions> container.  I'd go for an example like, say, so:

<feedback xmlns="http://ietf.org/xml-namesapaces/dmarc-xml/1.0">
    <report_metadata>
       ...
    </report_metadata>
    <policy_published>
       ...
    </policy_published>
    <extension_metadata name="bimi" xmlns="http://ietf.org/xml-namesapaces/bimi-xml?/1.0">
       ...
    </extension_metadata>
    <record>
       <row>
          ...
       </row>
       <identifiers>
          ...
       </identifiers>
       <auth_results>
          ...
       </auth_results>
          ...
       <extension name="bimi" xmlns="http://ietf.org/xml-namesapaces/bimi-xml??/1.0">
          ...
       </extension>
    </record>
    <record>
       ...
    </record>
</feedback>


Third, we need to grasp how XML grammars can be composed, and insert it in Appendix A.


>  At the time, I didn't intend to limit the extensions to IETF-approved extensions, though wasn't sure how else this might be used by reporting entities (I mentioned domain reputation-ish things during the call).  I'd consider that if we don't enforce IETF-registered extensions, the receivers could still ignore extensions they don't want to handle.


I assume no one reads the XML directly, except for debugging.  If report consumers don't know about an extension, its content will never reach human eyeballs.  Extension existence will have to be advertised, and a IANA page could be a decent means of doing that.


>  I'm also aware this could bloat a report in terms of size, though we've already indicated we don't seem overly concerned with the size of the XML body.  A few things I'd like to see the group reach consensus on are:
> 
> 1) Extensions in their own section (as it is now) or within each <row> element


Both, and both optional.  An extension can have some data to add in some <record>, but not necessarily in all of them.


> 2) Must extensions be IETF-approved


We cannot stop non-registered extensions.  Yet, developers may want to see an RFC before implementing code that extracts a given extension's content.


> 3) If (2) is true, do we want to define any during the DMARCbis process (essentially a demonstration of how it is to be done)


It would be a good way to show how to define them.  Not our primary task, though.


Best
Ale
-- 

> 1: https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-aggregate-reporting-02#section-4