Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

Alessandro Vesely <vesely@tana.it> Fri, 04 December 2020 08:21 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 CB9753A15B8 for <dmarc@ietfa.amsl.com>; Fri, 4 Dec 2020 00:21:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 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_DNSWL_BLOCKED=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 OL4B2rBNfhP1 for <dmarc@ietfa.amsl.com>; Fri, 4 Dec 2020 00:21:40 -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 2DE773A15AD for <dmarc@ietf.org>; Fri, 4 Dec 2020 00:21:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607070097; bh=H2/LfkHc5Mj3RDV7CwGxkBt2oDqSpg90QSVrq8gISIo=; l=2197; h=To:References:From:Date:In-Reply-To; b=CvQ7t82iceHlN2vlX+cLX9r7GB+UDdAOpfCx93oMdeBbrn6r0eXjQwpCorYuxm5cf JxvUUAIt1S+lhzfZsjG0tUFhms//TM+zlMH2VEVIM/XRQZXAfvVK67LtNqbL4OSEi5 D8v2CNl/QuD+GNP8jX2Bi1GZ4wc8fsPXJh/XgX2fLIsUyakQyWLY4Fh38CCPd
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 00000000005DC056.000000005FC9F190.00002814; Fri, 04 Dec 2020 09:21:36 +0100
To: John R Levine <johnl@taugh.com>, dmarc@ietf.org
References: <20201202233432.D45FB28E1943@ary.qy> <f719b86d-9a7d-f865-3e16-10eaf35e0de0@tana.it> <479cfb50-b98e-fbbe-e7ce-375557cd624@taugh.com> <f406f70b-3f98-a8fd-db9d-956c000f5c68@tana.it> <a4c256c2-d0a3-1fc1-b585-7b8659cd6a4@taugh.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <0a650f5d-c53d-ab45-4125-6491c413f70b@tana.it>
Date: Fri, 4 Dec 2020 09:21:36 +0100
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: <a4c256c2-d0a3-1fc1-b585-7b8659cd6a4@taugh.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/dyut4seHAy_MVV56ABUd74Vb1Pg>
Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality
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 Dec 2020 08:21:42 -0000

On Thu 03/Dec/2020 20:54:03 +0100 John R Levine wrote:
>>> 
>>> Why do you believe that people would not send reports by mail and by https
>>> at the same time?
>>
>> Oh my.  Hadn't thought about that.  It will certainly cause duplicates.
> 
> I meant "at the same time" as in during the same reporting run.  As Dave noted, 
> if you sent any particular report by https, there's no need to send it again by 
> mail.


Got it.  However, the spec says it's a list of addresses to which aggregate 
feedback is to be sent.  When there are multiple entries, up to now, reports 
are sent to each.  If services like dmarcian switch to an https URI, a sender 
could end up with that URI along with its local mailto one.  How does a report 
producer know whether multiple URIs are mutually exclusive or inclusive?


> Systems receiving reports have to be prepared for duplicates anyway since 
> double deliveries of mail messages happens.  That's the point of the filename 
> on the report, to provide a unique name for each report so it's easy to tell if 
> you've seen a report before.


Right, but if that happens everyday the (small) efficiency gain is lost.


>> $ gpg -u 500982D49712C507C236B2D6B8ABBBF9A091CC0D --clearsign < this text
>>
>> Can you verify it?  I cannot find how to transform the delta selector public 
>> key into a pgp public key block.
> 
> It says it can't find a public key which is not surprising.  I still don't 
> think this is a productive direction to go.


Not for the subject at hand, maybe.  The possibility to further deploy DKIM key 
distribution by coding some dkim2openpgp utility seems interesting to me.


> If people really are worried about fake reports, there is a well defined way to 
> put a signature in an XML document.


However, XML signatures require a certificate, not just a key.  Consider that a 
DNSSEC-authenticated DKIM signature is semantically superior to CA 
certificates.  First, because registrars know what they're signing better than 
CAs.  Second, because the way to associate DKIM signatures with the issuing 
domains is better standardized than X509 subject common name or alternative name.


Best
Ale
--