Re: [dmarc-ietf] AutoForward problems - Change log benefits to mailing lists
Although I re-raised the change log issue as part of the auto-forward problem, I am hoping that it will have significant benefit to the mailing list community also. Of the three types of content changes that I proposed, the easiest to specify and get implemented is the first type, where the mediator only adds content, adds a change log indicating the additions, and signs the result. I am hoping and assuming that if mailing lists have freedom to add their branding to the subject and body, most lists would not need to make more complex changes. The signed change log would allow participating recipients to identify the signed additions added by the list or other mediator, while also identifying the signed original after the list additions are virtually removed. Once the additions and the original are reliably identified to a source domain, suspicion of spoofing is no longer a concern. Each chunk of content can be evaluated based on the reputation of the verified source domain and the specifics of the content. Nested additions are possible.Each new signature adds an entry to a verification stack. Any change can be removed, virtually or actually, by reversing the change at each level, working backwards from last to first. In practice, the stack is expected to be short. To prevent malicious misuse, the specification should put a small limit on the number of layers in the stack. Just as importantly, I believe it solves the problem of letting the list know whether From rewriting is necessary or not. I argue that there is no information-leakage risk associated with a domain publishing a DNS entry that says "This domain understands multi-author documents of type 1".This type of flag says nothing about what the domain will do with any particular message with multiple authorship. The recipient domain will have the option of passing the entire message, stripping the wrapper and passing the original, or blocking the whole thing. But it will not be blocking a message because it does not understand the message's actual identity, which is the cause of our current problem. Once a list knows that its identity will not be misjudged, it gains the freedom to assume that its content will be judge fairly, so "From" rewriting should not be necessary when sending to domains that have published this flag. Because this approach adds confidence rather than risk, I am hopeful that even AOL would be willing to implement support for it. The more complex changes, edits and deletions, require a more complex specification and more complex code. That level of specification will be needed to provide a solution to spam filters that do URL rewriting. But that complexity can wait for another day while we try to get a level 1 change log accepted. John, I am hoping that you find some opportunity here. Do you? Doug Foster From: "John Levine" Sent: 9/3/20 6:44 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] AutoForward problems In article <767e2dcc-e87c-1e90-2f86-486e51a3c...@wisc.edu>, Jesse Thompson wrote: >I realize that John's message in the other thread probably wasn't referencing >auto-forwarding, but I think his point >dovetails to the auto-forwarding issue: > >> As always, as I hope we all remember DMARC alignment doesn't mean not spam, >> and you still do all of the stuff you do to sort your mail. ... As you say, it's the same problem, it's what people see as the same message but with changes that fail with current authentication schemes. >a) It assumes that the domain owner has the ability and desire to authorize >every potential forwarder, even though >auto-forwarding is a user-level decision. It's not the domain owner, it's more likely the MTA deciding what signatures to apply. >c) Selectively allowing forwarding at the user level is difficult because >users are gonna do what they wanna do (you >try telling faculty they can't forward). It's not the case that all >enterprises want to prohibit all of their users >from auto-forwarding (even though that's the answer you may get if you survey >the CISO community) Yeah. The likely damage from allowing wisc.edu to forward seems pretty low, the damage from outlook.com or gmail.com considerably more. R's, John -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] AutoForward problems
In article <767e2dcc-e87c-1e90-2f86-486e51a3c...@wisc.edu>, Jesse Thompson wrote: >I realize that John's message in the other thread probably wasn't referencing >auto-forwarding, but I think his point >dovetails to the auto-forwarding issue: > >> As always, as I hope we all remember DMARC alignment doesn't mean not spam, >> and you still do all of the stuff you do to sort your mail. ... As you say, it's the same problem, it's what people see as the same message but with changes that fail with current authentication schemes. >a) It assumes that the domain owner has the ability and desire to authorize >every potential forwarder, even though >auto-forwarding is a user-level decision. It's not the domain owner, it's more likely the MTA deciding what signatures to apply. >c) Selectively allowing forwarding at the user level is difficult because >users are gonna do what they wanna do (you >try telling faculty they can't forward). It's not the case that all >enterprises want to prohibit all of their users >from auto-forwarding (even though that's the answer you may get if you survey >the CISO community) Yeah. The likely damage from allowing wisc.edu to forward seems pretty low, the damage from outlook.com or gmail.com considerably more. R's, John -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] AutoForward problems
On 9/3/20 4:33 PM, Doug Foster wrote: > OAUTH vs. More careful forwarding > > Pursuing both techniques makes the most sense.Some users may be > unwilling (or not allowed) to store credentials in the target server, while > being unwilling to do a manual operation to obtain their new messages. OAuth, as opposed to basic authentication, does not require the user to share their password with a 3rd party. The OAuth access token is a credential, but it's individualized to the app using it, and can be revoked. The manual operation only comes into play during authentication (and whatever session length requirements are imposed by the provider). I'd say the manual effort is a wash, and the opportunity to introduce re-authentication at periodic intervals improves security and prevents forgotten configurations from persisting. > Since OAUTH is a pull operation instead of a push, it provides several > benefits: > - Certainty that the forwarding target actually wants the message. > - Near-certainty that the message will be accepted by the client system, > since the pull bypasses the SMTP filtering process. This includes both > sender authentication issues like DMARC as well as other content filtering > applied by the forwarding target's domain. > > You point out the organizational politics will affect the process: > - For consumer-focused services like Gmail and Hotmail, the user owns the > data and has primary control over its disposition. > - For centralized organizations (most large companies), the organization > owns the data and can control its disposition. > - For decentralized organizations like your university, control is > effectively shared and negotiated. Right, and the organization can (or should be able to) configure policies to manage this shared relationship; potentially allowing for consumer-focused services to move a bit in one direction, and centralized organizations to move a bit in the other. > Forwarding Control Mechanism > -- > With any of the above political structures, I argue that the user should not > have sole control over the forwarding process. > > Assume that UserA@DomainA wants to forward to UserB@DomainB: > > DomainA interests include: > - If DomainB objects to the messages for any reason, it may blacklist > DomainA and cause disruption to traffic other than this one user's messages. > - The forwarding action may violate company confidentiality or > organizational obligations to protect privacy of others (GDPR, PCI DSS, > HIPPA, etc.) > - DnmainA may want to assess whether the forwarding request is in good > faith, and that it is not a mule account for exfiltration of data. > > DomainB and UserB@DomainB interests include: > - Does UserB actually want these messages? > - What if UserB is the victim of a typo? > - What if the auto-forward is being implemented as an attack vector on > UserB? > - What if the auto-forward is going to a non-existent account because of a > typo? > > DomainA would benefit from registering the forwarding configuration with > DomainB: > - So that if DomainB has more aggressive spam filtering, the blocked traffic > will be blamed on the source and not on DomainA. > - So that DMARC verification failures can be overlooked. > - More generally, so that DomainB does not perceive UserA@DomainA as an > open relay or other threat vector. > - If the account is overquota or closed, DomainA has an interest in > receiving notification of this event. > > Consequently, I think the protocol should be: > - UserA@DomainA requests forwarding from his domain owner. > - DomainA requires a confirming email from UserB@DomainB, which should be a > trivial effort for UserA@DomainA to make happen. > - DomainA decides how much to engage the domain owner of DomainB for > purposes of registration and whitelisting. > - Assuming that no veto is received, DomainA activates the forward. > > Outbound gateways can / should be used to enforce a domain's controls on the > forwarding process. > > This is very different from what I have seen implemented in mail store > products. Many systems allow any user to forward anywhere. Some systems > allow the domain administrator to disable all forwarding from any account. > I do not think I have seen admin-controlled selective forwarding, but others > have more product experience than I do. We do implement some controls over who can forward, and where those users can forward, and who can tell which users where they can/cannot forward. It's all custom, of course. I'm unsure how common it is. The UX comes into concern because when the user is forwarding out of the system they are disengaged with that system. How does the system communicate to the user that some new policy is in effect short of sending an email or stopping the mail flow and hoping they notice and call for support? With the fetch model, at least there are more
Re: [dmarc-ietf] AutoForward problems
OAUTH vs. More careful forwarding Pursuing both techniques makes the most sense.Some users may be unwilling (or not allowed) to store credentials in the target server, while being unwilling to do a manual operation to obtain their new messages. Since OAUTH is a pull operation instead of a push, it provides several benefits: - Certainty that the forwarding target actually wants the message. - Near-certainty that the message will be accepted by the client system, since the pull bypasses the SMTP filtering process. This includes both sender authentication issues like DMARC as well as other content filtering applied by the forwarding target's domain. You point out the organizational politics will affect the process: - For consumer-focused services like Gmail and Hotmail, the user owns the data and has primary control over its disposition. - For centralized organizations (most large companies), the organization owns the data and can control its disposition. - For decentralized organizations like your university, control is effectively shared and negotiated. Forwarding Control Mechanism -- With any of the above political structures, I argue that the user should not have sole control over the forwarding process. Assume that UserA@DomainA wants to forward to UserB@DomainB: DomainA interests include: - If DomainB objects to the messages for any reason, it may blacklist DomainA and cause disruption to traffic other than this one user's messages. - The forwarding action may violate company confidentiality or organizational obligations to protect privacy of others (GDPR, PCI DSS, HIPPA, etc.) - DnmainA may want to assess whether the forwarding request is in good faith, and that it is not a mule account for exfiltration of data. DomainB and UserB@DomainB interests include: - Does UserB actually want these messages? - What if UserB is the victim of a typo? - What if the auto-forward is being implemented as an attack vector on UserB? - What if the auto-forward is going to a non-existent account because of a typo? DomainA would benefit from registering the forwarding configuration with DomainB: - So that if DomainB has more aggressive spam filtering, the blocked traffic will be blamed on the source and not on DomainA. - So that DMARC verification failures can be overlooked. - More generally, so that DomainB does not perceive UserA@DomainA as an open relay or other threat vector. - If the account is overquota or closed, DomainA has an interest in receiving notification of this event. Consequently, I think the protocol should be: - UserA@DomainA requests forwarding from his domain owner. - DomainA requires a confirming email from UserB@DomainB, which should be a trivial effort for UserA@DomainA to make happen. - DomainA decides how much to engage the domain owner of DomainB for purposes of registration and whitelisting. - Assuming that no veto is received, DomainA activates the forward. Outbound gateways can / should be used to enforce a domain's controls on the forwarding process. This is very different from what I have seen implemented in mail store products. Many systems allow any user to forward anywhere. Some systems allow the domain administrator to disable all forwarding from any account. I do not think I have seen admin-controlled selective forwarding, but others have more product experience than I do. Doug Foster -Original Message- From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Jesse Thompson Sent: Thursday, September 03, 2020 8:42 AM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] AutoForward problems On 9/2/20 6:33 AM, Douglas E. Foster wrote: > For mailing lists, we have pushed the limits of authorization. But there is another class of problems where sender authorization is not feasible: mail which is auto-forwarded after a spam-filter has made content-altering changes. Yes, this is an increasing problem, as exemplified by the number of enterprises that have started tagging subjects and bodies with [External] warnings. Coupled with DMARC adoption, the ability for users to auto-forward successfully is shrinking. I realize that John's message in the other thread probably wasn't referencing auto-forwarding, but I think his point dovetails to the auto-forwarding issue: > As always, as I hope we all remember DMARC alignment doesn't mean not > spam, and you still do all of the stuff you do to sort your mail. > This scheme depends on the forwarders you authorize being > well-behaved. That's why I am concerned that senders need to be > selective about who they allow to forward. I am concerned with: a) It assumes that the domain owner has the ability and desire to authorize every potential forwarder, even though auto-forwarding is a user-level decision. b) It assumes that all potential forwarders check for authorization before forwarding -- essentially the same problem with the
Re: [dmarc-ietf] AutoForward problems
On 9/2/20 6:33 AM, Douglas E. Foster wrote: > For mailing lists, we have pushed the limits of authorization. But there is > another class of problems where sender authorization is not feasible: mail > which is auto-forwarded after a spam-filter has made content-altering changes. Yes, this is an increasing problem, as exemplified by the number of enterprises that have started tagging subjects and bodies with [External] warnings. Coupled with DMARC adoption, the ability for users to auto-forward successfully is shrinking. I realize that John's message in the other thread probably wasn't referencing auto-forwarding, but I think his point dovetails to the auto-forwarding issue: > As always, as I hope we all remember DMARC alignment doesn't mean not spam, > and you still do all of the stuff you do to sort your mail. This scheme > depends on the forwarders you authorize being well-behaved. That's why I > am concerned that senders need to be selective about who they allow to > forward. I am concerned with: a) It assumes that the domain owner has the ability and desire to authorize every potential forwarder, even though auto-forwarding is a user-level decision. b) It assumes that all potential forwarders check for authorization before forwarding -- essentially the same problem with the way most ESPs will use a domain in the From header without checking for authorization via DMARC. c) Selectively allowing forwarding at the user level is difficult because users are gonna do what they wanna do (you try telling faculty they can't forward). It's not the case that all enterprises want to prohibit all of their users from auto-forwarding (even though that's the answer you may get if you survey the CISO community) d) Selectively forwarding based on the knowledge of whether the forwarded message will reach the destination is challenging because the intermediary doesn't really know if it will succeed, and selectively forwarding in this way will lead to the user only seeing a subset of their messages being forwarded. This is essentially what's happening today (see my first sentence in this message), and I know users who are still bound and determined to auto-forward and they have just resigned themselves to the fact that they have to periodically check the intermediary mailbox for all of the messages that didn't survive the forward. > In the absence of such techniques, the forwarding system (or the outbound > gateway) needs to be aware that a message has been forwarded after > content-altering changes. When this is the case, the message either > requires a known exception at the receiving system or a From address rewrite > so the message will pass DMARC. At minimum, our DMARC specification should > make this clear. I agree with this, however, I'm increasingly of the mindset that since this is a user-level issue, we should be thinking about solving it via OAuth mechanisms. Modern email services do support the ability to fetch from a mailbox, authorized via OAuth, so it might be easier to convince the downstream mailbox providers to enhance their fetching mechanisms to support the features that people expect of inbound mail (i.e. apply inbound filtering rules). The mailbox provider would still need a way to determine the original DMARC results, spam analysis, etc, but wouldn't that be easier to implement since the message is "frozen in time" and wasn't subjected to the altering changes implied by forwarding? Jesse ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
