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

[Todd Herr <[e-mail]>]

On Wed, Jun 21, 2023 at 4:22 AM Alessandro Vesely <[e-mail]> 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.

-- 

*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* [e-mail]
*p:* 703-220-4153
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.