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

[Alessandro Vesely <[e-mail]>]

On Tue 20/Jun/2023 15:40:11 +0200 Todd Herr wrote:
> On Mon, Jun 19, 2023 at 8:25 PM John R Levine <[e-mail]> wrote:
>> On Mon, 19 Jun 2023, Patrick Ben Koetter wrote:
>>> I suggest that we do not only drop SPF, but also come up with better ways 
>>> (simplification, tools, exchange formats) to implement DKIM in order to allow 
>>> for a smooth transition.
>>
>> I'm scratching my head here.  On my system I publish and rotate DKIM keys 
>> completely automatically.  The only manual config is to edit the list of 
>> domains when I add or remove one from my mail server.  It's not totally 
>> trivial but it's not that hard.
>>
>> I suppose we could encourage people to implement ed25519 signatures since 
>> the keys are small and more likely to fit in a single TXT record string 
>> for provisioning crudware that doesn't handle multiple strings, but beyond 
>> that, what do you have in mind?
>
> 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?


Best
Ale
--