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

["Murray S. Kucherawy" <[e-mail]>]

On Thu, Jun 22, 2023 at 6:32 AM Todd Herr <todd.herr=
[e-mail]> wrote:

> Marty also has the right to engage a third party to send the mail (again,
> as conveyed by their employer), mail that Marty and others at Marty's
> company will create. The third party here is most commonly referred to, in
> my experience, as an Email Service Provider (ESP), but this is just one use
> case. The ESP knows how to DKIM sign messages, and can even do so using the
> domain of Marty's employer, so long as Marty is able to get the public key
> published in DNS.
>

We thought about this during the early DKIM days.  It was called out more
than once that at sufficiently large organizations, the email people and
the DNS people are not certain to be part of the same organization.  That's
certainly true where I work.  And at a subset of the largest of those
organizations, the email people and the DNS people don't trust each other
either, so they sometimes make it harder for one to tamper in the space of
the other.  We tried to keep this in mind while designing how DKIM could
function.

I concur that this isn't really a problem for either working group to solve
as part of a standard, but there might be room for some suggestions if
either one ends up producing a best practices document.

The open source DKIM package I developed included a simple tool that would
generate a properly formed TXT record and associated comments suitable for
inclusion into a zone file, but there was feedback that it was still error
prone.  It also included a script that, once you had published a DKIM
record, would confirm that your signing key and the public key now in the
DNS matched, so signatures should work.

I had two thoughts over the years about other things to try:

(1) Instead of generating a DNS TXT record for someone to cut and paste,
output a complete "_domainkey" zone file to simply move into position,
i.e., by copying files rather than strings.  This is less prone to
corruption because copy-paste isn't part of the process.

(2) Make use of protocols like DNS UPDATE (RFC2136) that could allow DKIM
key generation tools to insert new records directly into the primary
authoritative server.  This is even less prone to error or corruption
because the human is almost totally removed from the process.

-MSK