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
[dmarc-ietf] Namespace delegation limits
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. It would encounter several obstacles: - Evaluator participation: Senders have no information about whether their intended recipients will trust the signature - Domain owner participation: Would Gmail and AOL be willing to let individual account owner create DKIM keys of this type? - Scaling: What happens when the DKIM key path for a mailbox provider's domain is cluttered with millions of user-created entries? But there is probably a way to make it work. Doug Foster On Sat, Apr 1, 2023 at 9:04 PM Jesse Thompson wrote: > On Sat, Apr 1, 2023, at 8:04 AM, Douglas Foster wrote: > > For purposes of the following discussion, assume that messages from > known-bad senders and messages with unacceptable content have already been > blocked. The question at hand is how to handle Sender Authentication > failure when a message has no other objectionable characteristics. > > There are three possible states for a message that is unauthenticated but > otherwise unobjectionable: > > 1) Authorized by domain owner but not verifiable due to configuration > errors or omissions by the sender. > > 2) Authorized (implicitly or explicitly) by a single domain member, or > sent for their benefit. Inherently not verifiable with domain-level > validation. Mailing List messages are one example in this category. > > 3) Not authorized by anyone and therefore illegitimate. > > This framework applies to any unauthenticated message, including DMARC > FAIL or NO POLICY, as well as SPF FAIL, SOFTFAIL, PERMERROR, NEUTRAL or > NOPOLICY. > > Category 1 and 2 are (by assumption) legitimate messages, but without > authentication they are indistinguishable from Category 3 illegitimate > messages. > > A DMARC policy of p=reject says that there will be no Category 1 messages. > Even when true, it does not resolve the ambiguity between Category 2 and > Category 3. The only way to resolve ambiguity is with more information. > One important aspect of this question is whether the user wants the message. > > I have two approaches for handling these unauthenticated messages. > - Relaxed mode: Deliver the message to the user, then perform an in-depth > review after the fact. > - Strict mode: Deliver the message to system quarantine, then review > before releasing to the user. > > System quarantine is used because: > - I understand how to view and interpret the message headers. > - The quarantine review tool can present the message in a safe-mode view > - My user-mode quarantine review tools do not provide the user with enough > information to make an intelligent decision. > > This approach works well for me, but it does not work for Big Tech because > it requires too much labor. Instead, the work needs to be distributed by > sending "Strict Mode" messages to user quarantine. This requires a > creation of user quarantine wizards that help the user make an intelligent > decision and automate the creation of disposition rules to affect future > messages. > > With any review, the goal is to characterize a message stream of which the > current message is an example. In some cases, it may be unclear how to > convert individually approved messages into a message stream definition. > Big Tech is likely to be pretty good at this, but their inference engines > could be assisted by information provided from the message source, using a > URI header like this > > > I have been thinking lately of an intent-based model that seems similar to > what you describe. What I am referring to as intents are what you are > referring to as operating policies. > > The customer of an ESP (the author) wants to do X, Y, Z. That is their > intent, expressed in good faith. Presumably. The ESP offers guidance on > deliverability practices to help the customer be successful with their > objectives. A common agreement between the customer and the ESP can be > established. The ESP wants to enable the customer to do what they stated, > but cannot guarantee that the customer might stray from their intent or be > lying. What actually happens in practice can be validated. Stray from > intent can be measured. In theory. > > Ultimately, the ISP decides whether to trust the mail. Currently, the > customer needs to warm up their reputation because the ISP has no idea who > the customer is and what their intent is. They are protecting themselves > from the risk that the customer might suddenly stray from their predictable > flow of harmless mail. If the customer does something the ISP