On Sun, Apr 2, 2023, at 9:25 AM, Jim Fenton wrote:
> On 2 Apr 2023, at 4:19, Douglas Foster wrote:
>
> > Jesse observed that ESPs sometimes have difficulty getting a delegated DKIM
> > scope, because it delegates authority an entire namespace:
> >
> > With an assist from the DKIM group, we could specify that a DKIM signature
> > without a "d=" term is valid. The "i=" term would have to be a full email
> > address and the key lookup would be done by parsing the domain portion of
> > the "i=" term. Then the DKIM signature becomes valid for DMARC only when
> > the entire "i=" address matches the full RFC5322.From address.
>
> Regardless of whether that’s a good idea, that would be an enormous change in
> the way DKIM works and would not happen given the scale of existing
> deployment.
I was discussing implementing using an ATPS lookup, not changing DKIM
> Besides, what’s the difference between this and just including the From
> address in the DKIM signature?
It's not about whether the address can be authenticated. It's about whether the
delegated DKIM signer should be able to have signing authority of the entire
address space when the domain owner has a least-privilege approach to security
matters.
> I think what you are looking for is a way to delegate a key that is valid for
> only a specific address, rather than the whole domain.
Or valid for multiple addresses, yes. I'm thinking: change ATPS to include the
hashed local-part of the 5322.From when constructing the "._atps." DNS query.
<hashed_d_signer_domain>.<hashed_rfc5322.from_localpart>._atps.<rfc5322.from_domain>
The signer only needs a single key (for their own domain, no need for DKIM DNS
delegation) and the domain owner only needs to publish a TXT record for each of
the localparts within the rfc5322.From domain they choose to delegate to the
signer's domain.
Otherwise, as I mentioned, I don't see what ATPS brings to the table which
isn't already possible with DKIM via CNAME record delegation.
> Why not just create a subdomain for the ESP to use like marketing.example.com
> and publish keys there?
I think I said that. That is ideal.
In the world of enterprise IT, starting a suggestion with "why not just..." is
good way to learn how complex an organization really is (after the sarcastic
griping). Sometimes organizations insist on using their organization domain for
mixed-use purposes, or have been doing so for a long time and don't want to
change, people pull rank and refuse to change, the person who can make the
change is long gone, some legacy monolith needs to be upgraded first, or
whatever happens inside a complex organization. The domain owners (email/dns
administrators) aren't going to it find very helpful to point at the RFC where
it says "MUST NOT do the thing that we and our peers have been doing and things
seem ok anyway".
The discussion has been circling around this idea that domain owners are doing
a wrong/naive thing by publishing p=reject on their mixed-use domains. But they
are doing it anyway. Don't real-world implementations carry weight? Why are
they doing it? They are doing it because they think they value the perceived
security benefit. People who value security value least-privileged delegation
of authority.
If such a mechanism existed, the domain owner might choose to use it to
delegate the ability for random employees to use the few remaining
non-rewriting mailing lists without having to sacrifice the perceived security
benefits for their entire domain/user-base.
Jesse
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
