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

Alessandro Vesely <vesely@tana.it> Tue, 29 September 2020 17:46 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 35E8E3A0F54 for <dmarc@ietfa.amsl.com>; Tue, 29 Sep 2020 10:46:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.31
X-Spam-Level:
X-Spam-Status: No, score=-2.31 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.213, RCVD_IN_DNSWL_BLOCKED=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 59IfEC7GkLKB for <dmarc@ietfa.amsl.com>; Tue, 29 Sep 2020 10:46:35 -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 4D42A3A0F51 for <dmarc@ietf.org>; Tue, 29 Sep 2020 10:46:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1601401591; bh=hjbRRe8zwI970Y+eQC9LWCUCX24nPJ4WM0GLN+KWm/Q=; l=1503; h=To:References:From:Date:In-Reply-To; b=BTFWyeCpel0afXbU1Pz3k6z9Nvt9Km5OTzYN2dCBtCTMUCLE/gHO9ErIOej46G/g2 LH2/gBhL7oaocUN+L9Z0Z7u/T2jukZQvkzh0+L5zfcw/gQ2y6ZO+kzk6rZ0qGtCO3h SNg/S3+OiQ0XKDtc5eRHuvF/+htY6sS0S/XwKvnZpCvaWS0nuriEhLCmd72ds
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 00000000005DC08B.000000005F7372F7.0000557E; Tue, 29 Sep 2020 19:46:31 +0200
To: dmarc@ietf.org
References: <20200927171611.838B321D9BAD@ary.qy> <5069099.lO0Lvmlme3@zini-1880> <a4e016ba-673a-81f0-829b-b3b7adb6fcac@dcrocker.net> <5F73393D.4010805@isdg.net> <7afb25f6-c258-e92c-fdfe-10fe26ccecec@dcrocker.net>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <ccfbbfb3-5e7f-3022-90be-c4a7e86c298a@tana.it>
Date: Tue, 29 Sep 2020 19:46:31 +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: <7afb25f6-c258-e92c-fdfe-10fe26ccecec@dcrocker.net>
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/lp2Thvnp6iETxY7RvayaBUMD1u4>
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: Tue, 29 Sep 2020 17:46:37 -0000

On Tue 29/Sep/2020 19:26:21 +0200 Dave Crocker wrote:
> On 9/29/2020 6:40 AM, Hector Santos wrote:
>> On 9/27/2020 11:44 PM, Dave Crocker wrote:
>> DKIM has a single signature binding requirement, the 5322.From
>>> DMARC establishes the relationship.
>> I don't read it that way.
>>
>> DKIM binds the signer d= domain and the from.domain with no enforcement on it 
>> nor any indication that they are related when they not the same (the missing 
>> link). 
> 
> 
> Absolutely not.  Please re-read the DKIM specification more carefully. It is 
> quite explicit that it is doing not doing this.


I think that by "binding" Hector meant this:

5.4.  Determine the Header Fields to Sign

    The From header field MUST be signed (that is, included in the "h="
    tag of the resulting DKIM-Signature header field).
                        https://tools.ietf.org/html/rfc6376#section-3.4

The spec doesn't say why, but obviously holds that the From: domain is a 
specially meaningful one.  There are various other passages, for example:

    The order in which Verifiers try DKIM-Signature header fields is not
    defined; Verifiers MAY try signatures in any order they like.  For
    example, one implementation might try the signatures in textual
    order, whereas another might try signatures by identities that match
    the contents of the From header field before trying other signatures.
                        https://tools.ietf.org/html/rfc6376#section-8.15

(I think this can be an answer to part [2] of ticket #38.)


Best
Ale
--