Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

Alessandro Vesely <vesely@tana.it> Thu, 22 June 2023 09:54 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 F2F3DC14CF09 for <dmarc@ietfa.amsl.com>; Thu, 22 Jun 2023 02:54:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 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_HI=-5, 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, URI_NOVOWEL=0.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=tana.it header.b="GOF1hDO+"; dkim=pass (1152-bit key) header.d=tana.it header.b="AtFLMs/I"
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 1rDA04CCmLyJ for <dmarc@ietfa.amsl.com>; Thu, 22 Jun 2023 02:54:53 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [94.198.96.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42F4C151707 for <dmarc@ietf.org>; Thu, 22 Jun 2023 02:54:50 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1687427688; bh=6/IXHtbZMDoIKeACjj41YCXcJtFiiPva4l3z81J+wIo=; h=Author:Date:Subject:To:References:From:In-Reply-To; b=GOF1hDO+X5/3hu1TtQtZBDOV8l7GRC55iIDDCEwvQUSUpQu4jGtr5kD3nDY0o1Myo 19lNfIlYFaKoJYeRLWNBQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1687427688; bh=6/IXHtbZMDoIKeACjj41YCXcJtFiiPva4l3z81J+wIo=; h=Date:Subject:To:References:From:In-Reply-To; b=AtFLMs/I2C/VVpTcYtej8UlcJFaASzQKZ656oSewETmmzndOP/McH0ipl5EVPcr/L znSAbMTR+/057txcb3CHT09nQL4ruIz4YyUjVA936DpEZPKWB5pgtqrmUV7g3aNhsT opU8NY4r4uEqxvQVoUin4bADfAwQPA3QssrPEhM1t15WoSeWnyfFleWNatVgc
Original-Subject: Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal
Author: 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.0000000064941A68.00000344; Thu, 22 Jun 2023 11:54:48 +0200
Message-ID: <f6f3aeb5-2e82-ff6a-583c-f537240919d1@tana.it>
Date: Thu, 22 Jun 2023 11:54:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0
Content-Language: en-US, it-IT
To: dmarc@ietf.org
References: <30BB83B2-B454-41B8-992B-8E2569802D9C@1und1.de> <D225D7FC-C570-4B63-A694-9F16DB1F33E1@kitterman.com> <CALaySJKwuOK-81dW2H9dtURxa5mLQDUNo+MWcs+Hho8N+yP9qg@mail.gmail.com> <2817813.dRqVH37e0G@localhost> <CALaySJJbPFBAV_7mZaARYWuMzuX+74r2Cm0jD+z92_iuFRn_MQ@mail.gmail.com> <25736.57534.195344.782189@fireball.acr.fi> <1ec42959-977a-9ce0-907a-83a5eb2b6ef2@tana.it> <25739.5435.550786.601699@fireball.acr.fi> <25739.33240.127804.524371@fireball.acr.fi> <5d9a0b0f-8777-2494-d779-376c6ab8b37d@tana.it> <xtudkqv5sqxs4c2nnilna5lf4b266br4xwdjwoq4fdyjpgzjln@xdb5rldfeini> <3087d0fa-91b4-62b4-fc64-a705c7f0b672@taugh.com> <CAHej_8=VnOC1Pms2JKJYG=2Dqtp2nc9oe-j=aEmNfvGuNhvzZA@mail.gmail.com> <a9505fda-ed21-1fc6-adb6-f231225a1ceb@tana.it> <CAHej_8nNGQR9Bm59dsu=XG7iBGyyW=SCh4=0cBM8NWodHyo6pQ@mail.gmail.com>
Authentication-Results: tana.it; auth=pass (details omitted)
From: Alessandro Vesely <vesely@tana.it>
In-Reply-To: <CAHej_8nNGQR9Bm59dsu=XG7iBGyyW=SCh4=0cBM8NWodHyo6pQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/HrhSKotMoHStNgYIW9OppEVMaTM>
Subject: Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal
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: Thu, 22 Jun 2023 09:55:00 -0000

On Wed 21/Jun/2023 15:36:44 +0200 Todd Herr wrote:
> On Wed, Jun 21, 2023 at 4:22 AM Alessandro Vesely <vesely@tana.it> wrote:
>> On Tue 20/Jun/2023 15:40:11 +0200 Todd Herr wrote:
>>>
>>> I can't speak for Patrick, but I don't think he's necessarily thinking of 
>>> different encryption algorithms here.
>>>
>>> Not all who wish to have their email DKIM signed have the luxury that you 
>>> have John of full control of the DKIM signing process. I'm specifically 
>>> thinking of the entity (call them Marty Marketer) who has the authority to 
>>> employ a third party to send authenticated mail on behalf of a domain, mail 
>>> that the third party can and will DKIM sign using the entity's domain. 
>>> Sadly, Marty does not have the authority to update DNS for that domain in 
>>> order to publish a DKIM public key. This leads to challenges as the third 
>>> party presents to Marty a public key to publish, and Marty tries to figure 
>>> out to whom to pass along this information and in what format. This leads 
>>> to screen caps, or cutting and pasting errors, misdirected mail chains, 
>>> etc., etc.
>>>
>>> Is this the way it should be? Probably not, but it's a reality for many, 
>>> and it's a problem we don't as an industry have an answer for yet. If we 
>>> did, there wouldn't be people in the other thread reporting such a high 
>>> percentage of DKIM failures due to malformed/missing keys.
>>>
>>> Now, of course we could argue that Marty shouldn't be left to their own 
>>> devices to engage third party senders, and that should solely be the 
>>> province of the IT staff that manages DNS, but I fear that the energy 
>>> required to type and distribute such words would be wasted.
>>
>> Creating more and more publishing mechanisms could reproduce the situation of 
>> SPF, whereby customers of the same third party can easily impersonate one 
>> another.
>>
>> DKIM signatures have to be created by MSAs upon user authentication.  MSAs 
>> which use smarthosts, IMHO, had better sign just the header fields they 
>> control rather than delegate signing.  Doesn't Marty have any option on that?
>
> I'm afraid I've done a poor job of making my point, as it seems that you 
> haven't understood what I was trying to say. Let me try again.
>
> The scenario I'm describing here isn't referring to the actual DKIM signing 
> of any given message. Rather, I'm talking about the publication of the DKIM 
> public key in DNS to support the validation of signed mail.
>
> In this scenario, Marty has hired a third party email service provider 
> (e.g., WeSendMail) to handle a class of bulk sending on behalf of Marty's 
> organization (e.g., WeSellStuff.com).
>
> Marty wants WeSendMail to DKIM sign that mail using d=wesellstuff.com, and 
> WeSendMail can do that, so Marty clicks a button or whatever in the 
> WeSendMail UI to make that happen.
>
> The UI pops up a screen that says "Please publish this TXT record in your 
> DNS", where the name is WSMWSSSelector._domainkey.wesellstuff.com and the 
> value is the DKIM public key. Marty doesn't control DNS for wesellstuff.com.
> 
> Maybe Marty knows who does control DNS, and Marty is good at cutting and 
> pasting, and Marty can successfully communicate the request to the DNS 
> people for wesellstuff.com.
>
> Maybe Marty has no clue who to engage, or maybe Marty misses a character in 
> the cutting and pasting, or maybe Marty just does a screen capture and the 
> DNS folks mess up something when transcribing the contents of the picture, 
> or...
>
> Might something like Domain Connect (https://www.domainconnect.org/) solve 
> this? Sure, it could, and its website even describes a scenario identical 
> to what I'm trying to describe here. However, Domain Connect seems to be a 
> bit hand-wavy on the concept of authorization when it comes to making 
> changes to DNS zones, and in this scenario, Marty doesn't have those 
> credentials.


Ah, yeah.  I had thought that the message content was written by people at 
wesellstuff.com and sent on their behalf.  If it's people at WeSendMail who 
actually creates the messages, then it is correct that they sign what they 
write.  I understand the key publishing problem, although in the realities I 
have experience of, that kind of agreement is handled at a high enough level 
that Marty wouldn't have problems to ask it to the it head directly.

 From a recipient POV, I'd prefer From: to refer to the creatives and the 
subject to the advertised product...


Best
Ale
--