Re: [dmarc-ietf] Namespace delegation limits
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. .._atps. 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
Re: [dmarc-ietf] Namespace delegation limits
It would not have to be an incompatible change, we could just change the way DMARC interprets signatures: If the "i=" term includes a local-part, then the signature is only valid for that one From address (regardless of the domain alignment policy). Otherwise, the signature is valid for any address local-part in any domain or subdomain that matches the DMARC alignment policy. Installations based on RFC 7489 will continue to interpret the signature broadly. This eliminates compatibility concerns, while weakening the effectiveness of creating a new control for domain owners. My impression is that fully qualified addresses are relatively rare on DKIM scopes used for email, so I really don't expect that a change in interpretation would have much effect on existing mail streams. But that is an assumption rather than a known fact. Perhaps we could work together to collect some data to assess whether the change would be trivial or significant. As to the subdomain technique, Jesse indicates that it is used sometimes, but transitioning can be difficult even when it is used. More importantly, it is not applicable to a small business that uses a mailbox provider account, yet wants to use ConstantContact for some marketing newsletters. That small business does not have the option of obtaining a Gmail subdomain. In short, we have two groups of unhappy users, and we need to acknowledge them both: mailing lists and ESPs. Doug Foster On Sun, Apr 2, 2023 at 10: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. Besides, what’s the difference between this and just including > the From address in the DKIM signature? > > 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. Why not just > create a subdomain for the ESP to use like marketing.example.com and > publish keys there? > > -Jim > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Namespace delegation limits
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. Besides, what’s the difference between this and just including the From address in the DKIM signature? 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. Why not just create a subdomain for the ESP to use like marketing.example.com and publish keys there? -Jim ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
