Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations
In article you write: >Why should the rest of end-users suffer? (some might say) > >Granted, we are a university. Maybe these are just faculty being >hyper-sensitive to how >their messages are appearing to their peers/students. But isn't that enough >evidence that >end-users *are* relevant? With time, maybe we can change these end-user >expectations, and >From rewriting will be the new reality that people will accept. I don't think the claim is that users don't see anything, it's that they're no good at using what they see to make security decisions, something that has more to do with mental models and metaphors between what's on the screen and reality. >I think that draft-kucherawy-dkim-transform-02 is getting at what I was >originally thinking. >In my opinion, MLMs will *always* need to munge, because they will never know >if an arbitrary >receiver will trust their non-munged mail. Giving the receivers a way to >un-munge (if they >can and/or want and/or trust) would be a productive path forward out of this >situation. We already have a couple of ways to do reversible message munging, starting with MIME message wrapping. In principle it works fine, in practice it's awful because MUAs don't show wrapped messages consistently and often in ways that are painful, e.g., you can see the original author address but there's no button you can push to respond to it. Unwrapping a MIME attachment is a lot easier than the proposed DKIM unmunging but I doubt either is going to show up in MTAs any time soon. Perhaps you could do it in the mail gateway. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations
On 7/20/2020 6:18 PM, Murray S. Kucherawy wrote: I'm not sure we've ever fully faced the idea that what MUAs choose to display needs to be factored into the evolution of these protocols. For as long as I've been working on this, it's been the opposite. Although various people keep citing affecting display based on dmarc, that's never been the essence of its motivation. Which is good, because users are not affected by trust indicators. Really. Not. It's entirely reasonable to start with the idea that it might (or should) help end-user evaluation, but human factors don't serve the master of that kind of logic. To date, online experience is that users are essentially impervious to trust indicators.(*) Rather, DMARC serves to provide some clean data to the receiving filtering engine, which is the only venue that matters for email safety. (Well, and originating filtering engines, of course.) Not the MUA. d/ (*) Obviously, if you have some data to the contrary... -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations
On Mon, Jul 20, 2020 at 1:59 AM Laura Atkins wrote: > There was a research project done by an inbox provider and a major > supporter of DMARC presented at a MAAWG meeting a few years ago. They tried > adding trust indicators to the message list but found no statistically > significant behavioral changes by users. Given the conference policies, I > hesitate to mention it here, but there is research. There’s also a > conference paper I found, done by a computer science research team at VA > Tech that looked at this as well. > I remember something about the former. I'll see if I can find a public reference to it. "Data, data, data; we cannot make bricks without clay." > Most clients these days seem to be hiding the RFC5322.From domain from the > individual end users. Mail.app on OSX does unless you change that setting > specifically (and it seems every few upgrades they reset the setting and > then hide the checkbox again). The iOS mail app doesn’t even have a setting > to change that I’ve been able to find. I seem to remember the last time I > set up a mailbox on Thunderbird (pre-2016 election as I was tracking some > candidate mail) they also hid the 5322.From address. > I could be wrong but I seem to recall that at the time DMARC was published, this wasn't the case. (See my previous remarks about Gmail.) But I agree that it does seem to be the case now. I'm not sure we've ever fully faced the idea that what MUAs choose to display needs to be factored into the evolution of these protocols. For as long as I've been working on this, it's been the opposite. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC threat analysis needed
On Mon, Jul 20, 2020 at 1:42 AM Alessandro Vesely wrote: > On Sun 19/Jul/2020 20:13:46 +0200 Murray S. Kucherawy wrote: > > On Sun, Jul 19, 2020 at 3:14 AM Alessandro Vesely > wrote: > > > >>> Still unresolved, IMHO, is Dave's point about whether the RFC5322.From > >>> domain truly matters. > >> > >> While the opinions of big players are relevant, you yourself mentioned > >> that they tend to follow DMARC design. > > > > > Sorry, I said what? > > > Google strikes me as the kind of place that would make a decision > about what to show users based on data, so I was wondering if they > have any, because I seem to remember them talking about this back > when DMARC was in development. > [ > https://mailarchive.ietf.org/arch/msg/dmarc/P6-4mvdCrRVXEz6DQXGunBsRKqA/] > When I said "back when DMARC was in development", that meant Gmail had already done what I described, not that they were inspired to do what DMARC said. Gmail was part of that effort, in fact. So no, I didn't say "they tend to follow DMARC design". The order is backwards. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations
On 7/19/20 1:33 PM, dcroc...@gmail.com wrote: > The essential point that needs to be made is that standards like this MUST > NOT be cast in terms of what end users will do. In practical terms, this > work has nothing to do with end users. Really. Nothing. > > To the extent that anyone wants to make an affirmative claim that end-users > /are/ relevant to this work, they need to lay that case out clearly, > carefully, and with material that provides objective support.(*) I'll take a shot (admittedly, I'm having trouble keeping up with all of the points that have been made): We're migrating 30,000 lists, of various types/use cases, from a MLM provider that is DMARC-ignorant to one that munges the From. It rewrites the friendly-From in addition to the From address (this touches on Laura's point that even though some/most MUAs hide the domain, recipients still *see* something different) We have a DMARC policy published for our 500ish domains, and an increasing number of the domains of our external list members are publishing DMARC. DMARC enforcement (outside of our control) is also increasing - which motivates us to accelerate our transition to the DMARC-friendly MLM platform (one that rewrites the From) ** We have had many complaints from users about the From munging ** I could try to quantify, if that's the only way to prove the point that end-users matter and are relevant to this conversation. It calls into question whether we (or any domain) should publish DMARC policies. Gmail.com doesn't publish a DMARC policy, after all, and many people (such as some on this list) are using gmail.com to subscribe to lists, and they don't have to suffer the consequences of DMARC. Why should the rest of end-users suffer? (some might say) Granted, we are a university. Maybe these are just faculty being hyper-sensitive to how their messages are appearing to their peers/students. But isn't that enough evidence that end-users *are* relevant? With time, maybe we can change these end-user expectations, and From rewriting will be the new reality that people will accept. The To-rewrite strategy seems interesting, in a "From-rewriting is here to stay" assumed world, to force MUA behavior and to help mitigate the auto-collecting address problem. I think that draft-kucherawy-dkim-transform-02 is getting at what I was originally thinking. In my opinion, MLMs will *always* need to munge, because they will never know if an arbitrary receiver will trust their non-munged mail. Giving the receivers a way to un-munge (if they can and/or want and/or trust) would be a productive path forward out of this situation. I think that we just have to agree that From-munging by MLMs is a permanent reality. It needs to be documented more prominently (and promoted as part of the DMARC marketing) so that implementations are more consistent, so that un-munging tactics and/or MUA behavior can be consistently implemented. Jesse ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Agenda requests for Madrid IETF
We have a session on the books for IETF108, and would like suggestions from the group for the agenda, otherwise the chairs will choose relevant topics. Items in tickets or from the past month are all fair game. Thanks, Seth, Tim, and Alexey ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Returning focus to DMARCbis
There's been a healthy discussion on the list over the past month that's touched on several items within DMARC's charter, but are out of scope of the currently chartered phase of work (phase III). As Chairs, we've watched this discussions closely, because successful mitigation of loss of authentication due to indirect mailflow is a requirement for the success of a standards track DMARC document, which is the focus of DMARCbis. ARC has IETF consensus, is being actively deployed, and needs time to succeed or fail against its experimental considerations before the group revisits the work -- which would require a rechartering. We have a good deal of work to do on DMARCbis, and many open tickets. As we discussed we want to track all issues in tickets. The chairs will use the active tickets to lead the list discussion. We will get to all the issues. If you feel that there are items that were raised in discussions that still require group discussion, please add them to trac ( https://trac.ietf.org/trac/dmarc/report/1) per the process Alexey laid out: https://mailarchive.ietf.org/arch/msg/dmarc/rBWzfzDa_tOhaVdxFzUBYVi46QI/ If you have questions about this process or need help filing a ticket appropriately, please reach out to the Chairs directly at dmarc-cha...@ietf.org. Thanks, Seth, Tim, and Alexey ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations
The court system is a poor substitute for prior deterrence or attack disruption. DMARC seems to do both. The Internet limits the utility of legal remedies because of the difficulty of attribution, a problem which also DMARC helps to solve. Litigation is also hampered by jurisdictional boundaries that create little risk of consequences for the perpetrators of crime. This forum was proposed for upgrading DMARC from informational status to standard status. Instead, it has become a conspiracy to demolish it.The MLM problem will only be :"solved" if DMARC is completely abandoned, so that spoofing is once again uninhibited. Therefore, moving from normal IETF "suggestion" mode to "enforced" mode will be necessary to achieve what MLM proponents want. It is not what I am advocating; quite the reverse. I am advocating for MLMs to stop spoofing and make their peace with DMARC. DF From: Benny Lyne Amorsen Sent: 7/20/20 5:44 AM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations "Douglas E. Foster" writes: > Ultimately, this becomes a question of power. Do domain owners have > the right, with the help of their correspondents, to prohibit spoofing > (unauthorized use) of their digital identity? Domain owners are free to use the court system to assert trademark rights and copyright. They are also free to apply whichever seals of digital identity that they want, of course. > Or since they are technically leaseholders, not owners, are their > rights conditional? You seem to be laboring under the impression that domain owners have a right to compel mail recipients to respect a DRM scheme. This is not the case. You can try to sue Google to force them to reject incoming email with your domain in the From: field and no valid DKIM (or whatever) signature, of course, but I have a hard time imagining which right you would assert to make the suit successful. > Specificslly, do Internet insiders have the right to declare their > spoofing control efforts to be based on foolish premises, both > unnecessary and inconvenient, and therefore not allowed? No one, certainly not "Internet insiders" of which I am certainly not one, is stopping you from doing whichever spoofing control efforts you want on your systems. Feel free to keep p=reject on your domains. Many mail servers will keep using that as a signal among many others, rather than as a blanket reject. If you want recipient mail servers to change that policy you can either do it by convincing their administrators or by getting a law passed. So far you appear to favour the latter approach, with your focus on "prohibit" "unauthorized use" and "rights". The IETF is not a lawmaking body, so it appears there are better venues for you. ___ 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] Response to a claim in draft-crocker-dmarc-author-00 security considerations
Dotzero writes: > One might point to the fact that DMARC was just such an effort before > it was publicly published. While there was much criticism of this when > it was submitted to the IETF - "You just want us to rubber stamp this" > - there was no such intent. It had worked well within the group of > senders and receivers implementing it through private peering that the > effort was made so that any domain of any size, both senders and > receivers, could implement it if so desired. I think the adoption rate > in the wild speaks for itself (volume of mail covered by DMARC). Volume of mail covered by DMARC seems to be rather unimpressive unless you count p=none as covered. > You have left out one significant way of convincing receiver domains > and their admins. We used to have our CSRs (customer service) tell > people who received spoof emails (resulting in phishing, malware > compromise, etc.) from emails claiming to be from our domains that > they should contact their mail provider or email admin because the > problem could have been avoided if DMARC were being checked. We would > even provide them with the details and a form with all the information > in non-technical terms. It is amazing how quickly a provider pays > attention when their customers/users are complaining to them that the > provider could have prevented the heartache and grief but chose not > to. Again, this was for domains sending transactional mail with only a > limited number (intentionally) of role and support accounts. You can obviously do all that, but that is not what Douglas E. Foster advocated. > While IETF is not a lawmaking body, it has an impact on the decisions > of lawmaking bodies just as the decisions of lawmaking bodies can > impact the implementation of standards. Using the IETF as a way to get laws passed favouring ones business seems at best underhanded. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations
On Mon, Jul 20, 2020 at 5:44 AM Benny Lyne Amorsen wrote: > "Douglas E. Foster" writes: > > > Ultimately, this becomes a question of power. Do domain owners have > > the right, with the help of their correspondents, to prohibit spoofing > > (unauthorized use) of their digital identity? > > Domain owners are free to use the court system to assert trademark > rights and copyright. They are also free to apply whichever seals of > digital identity that they want, of course. > > > Or since they are technically leaseholders, not owners, are their > > rights conditional? > > You seem to be laboring under the impression that domain owners have a > right to compel mail recipients to respect a DRM scheme. This is not the > case. You can try to sue Google to force them to reject incoming email > with your domain in the From: field and no valid DKIM (or whatever) > signature, of course, but I have a hard time imagining which right you > would assert to make the suit successful. > > DMARC clearly recognizes and documents local policy. > > Specificslly, do Internet insiders have the right to declare their > > spoofing control efforts to be based on foolish premises, both > > unnecessary and inconvenient, and therefore not allowed? > > No one, certainly not "Internet insiders" of which I am certainly not > one, is stopping you from doing whichever spoofing control efforts you > want on your systems. > One might point to the fact that DMARC was just such an effort before it was publicly published. While there was much criticism of this when it was submitted to the IETF - "You just want us to rubber stamp this" - there was no such intent. It had worked well within the group of senders and receivers implementing it through private peering that the effort was made so that any domain of any size, both senders and receivers, could implement it if so desired. I think the adoption rate in the wild speaks for itself (volume of mail covered by DMARC). > > Feel free to keep p=reject on your domains. Many mail servers will keep > using that as a signal among many others, rather than as a blanket > reject. > > If you want recipient mail servers to change that policy you can either > do it by convincing their administrators or by getting a law passed. So > far you appear to favour the latter approach, with your focus on > "prohibit" "unauthorized use" and "rights". The IETF is not a lawmaking > body, so it appears there are better venues for you. > You have left out one significant way of convincing receiver domains and their admins. We used to have our CSRs (customer service) tell people who received spoof emails (resulting in phishing, malware compromise, etc.) from emails claiming to be from our domains that they should contact their mail provider or email admin because the problem could have been avoided if DMARC were being checked. We would even provide them with the details and a form with all the information in non-technical terms. It is amazing how quickly a provider pays attention when their customers/users are complaining to them that the provider could have prevented the heartache and grief but chose not to. Again, this was for domains sending transactional mail with only a limited number (intentionally) of role and support accounts. While IETF is not a lawmaking body, it has an impact on the decisions of lawmaking bodies just as the decisions of lawmaking bodies can impact the implementation of standards. One need only look at the "great firewall of China" as one example. Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations
"Douglas E. Foster" writes: > Ultimately, this becomes a question of power. Do domain owners have > the right, with the help of their correspondents, to prohibit spoofing > (unauthorized use) of their digital identity? Domain owners are free to use the court system to assert trademark rights and copyright. They are also free to apply whichever seals of digital identity that they want, of course. > Or since they are technically leaseholders, not owners, are their > rights conditional? You seem to be laboring under the impression that domain owners have a right to compel mail recipients to respect a DRM scheme. This is not the case. You can try to sue Google to force them to reject incoming email with your domain in the From: field and no valid DKIM (or whatever) signature, of course, but I have a hard time imagining which right you would assert to make the suit successful. > Specificslly, do Internet insiders have the right to declare their > spoofing control efforts to be based on foolish premises, both > unnecessary and inconvenient, and therefore not allowed? No one, certainly not "Internet insiders" of which I am certainly not one, is stopping you from doing whichever spoofing control efforts you want on your systems. Feel free to keep p=reject on your domains. Many mail servers will keep using that as a signal among many others, rather than as a blanket reject. If you want recipient mail servers to change that policy you can either do it by convincing their administrators or by getting a law passed. So far you appear to favour the latter approach, with your focus on "prohibit" "unauthorized use" and "rights". The IETF is not a lawmaking body, so it appears there are better venues for you. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations
> On 19 Jul 2020, at 19:08, Murray S. Kucherawy wrote: >>I'm less convinced by the notion that all of the RFC5322.From is >> disregarded by the preponderance of users when deciding what level of trust >> to put in the message's content. That suggests we blindly open and read >> absolutely everything, and I suspect that isn't the case. > 1. That's not what it suggests, at all > > Then I don't know what else you might mean by "end users do not reliably make > trust decisions based on /any/ of the information in the rfc5322.From field". > What other data exist upon which to make trust decisions in the display of a > mailbox? There was a research project done by an inbox provider and a major supporter of DMARC presented at a MAAWG meeting a few years ago. They tried adding trust indicators to the message list but found no statistically significant behavioral changes by users. Given the conference policies, I hesitate to mention it here, but there is research. There’s also a conference paper I found, done by a computer science research team at VA Tech that looked at this as well. This question is actively being studied and there is research out there. We don’t need to speculate or bring in individual opinions, we can look at the different studies folks have done. > 2. No doubt there is a better way to put this, but I'm not thinking of it, > and this isn't just my second thought on the challenge, but quite a bit more > than that: This demonstrates why the IETF is a very poor venue for > conducting human factors discussions. > > No argument here. > Again: There is quite a bit of experience demonstrating that providing trust > indicators to end users does not produce reliable -- ie, useful -- > decision-making by end users. > > We appear to be talking past each other. I wasn't talking about trust > indicators, but rather whether the RFC5322.From domain is visible.. I don't > have any reason yet to think trust indicators are effective. Most clients these days seem to be hiding the RFC5322.From domain from the individual end users. Mail.app on OSX does unless you change that setting specifically (and it seems every few upgrades they reset the setting and then hide the checkbox again). The iOS mail app doesn’t even have a setting to change that I’ve been able to find. I seem to remember the last time I set up a mailbox on Thunderbird (pre-2016 election as I was tracking some candidate mail) they also hid the 5322.From address. There was another comment elsewhere about why not change the 5322.from address if it’s not visible to the enduser, and there are 2 reasons I have for that: The ability to search for mail from a particular author and the ability to block mail from a particular author. Rewriting the From: address always breaks the first. Some mailing lists point the Reply-To: to the original author which means some kinds of filtering can trigger off that. Other mailing lists point Reply-To: to the list address, which breaks the second. Both things are important to mailing list usability. laura -- Having an Email Crisis? We can help! 800 823-9674 Laura Atkins Word to the Wise la...@wordtothewise.com (650) 437-0741 Email Delivery Blog: https://wordtothewise.com/blog ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations
On Sun 19/Jul/2020 20:33:46 +0200 Dave Crocker wrote: The essential point that needs to be made is that standards like this MUST NOT be cast in terms of what end users will do. In practical terms, this work has nothing to do with end users. Really. Nothing. [...] (*) I've seen one posting here or somewhere else that noted that letting bad mail through can lead to end-users being deceived. I'll claim that while true, it is not relevant, since the behavior happens after DMARC, and the like, are relevant. That is, DMARC, etc., do not inform the end-user behavior. Aren't those two paragraphs self-contradictory? If DMARC were dependable, maybe users would learn to trust From:. Or maybe not. Avoiding end user considerations cuts both ways. Yet, we can trust that if we do a well-defined, clear job, then the whole system will work better. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC threat analysis needed
On Sun 19/Jul/2020 20:13:46 +0200 Murray S. Kucherawy wrote: On Sun, Jul 19, 2020 at 3:14 AM Alessandro Vesely wrote: Still unresolved, IMHO, is Dave's point about whether the RFC5322.From domain truly matters. While the opinions of big players are relevant, you yourself mentioned that they tend to follow DMARC design. > Sorry, I said what? Google strikes me as the kind of place that would make a decision about what to show users based on data, so I was wondering if they have any, because I seem to remember them talking about this back when DMARC was in development. [https://mailarchive.ietf.org/arch/msg/dmarc/P6-4mvdCrRVXEz6DQXGunBsRKqA/] Brandon hasn't chimed in, yet. I Cc: him. I'd guess he can confirm that efforts to highlight the domain name in From: addresses, if any, are inspired, or at least encouraged, by DMARC development. By hijacking From:, DMARC tweaked email core somewhat, for the good and the bad of it. We can either go ahead or retreat, a threat analysis being needed to make that decision. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
