Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations
On Sun, Jul 26, 2020 at 9:42 AM Dave Crocker wrote: > On 7/21/2020 12:32 PM, Dotzero wrote: > > The original DMARC effort was, in fact, to detect actual cases of >> spoofing, namely unauthorized use of a domain name by outside actors. >> >> Different problem. >> > > Actually, part of the effort was to enable Sending domains to identify > their own mail that was being sent without aligned DKIM signing or from > places not authorized through SPF - in other words, not properly authorized > but legitimate, hence feedback loops. > > > As I recall, this was /not/ part of the original purpose of DMARC, which > was discussed strictly in terms of mail from bulk senders. > > What you describe was, rather, the basis for the later use, which is what > then started causing problems for mail going through Mediators. > Notice I didn't use the word "users" Many of the sending domains in the original effort had/have a complex number of mail streams for transactional mail from multiple domains (in some cases thousands), including through multiple 3rd parties. This is what I was referring to. 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
The link provided by Laura Atkins on 7/21 is relevant and worth reading.Sent from my Verizon, Samsung Galaxy smartphone Original message From: Dave Crocker Date: 7/26/20 2:35 PM (GMT-05:00) To: hsan...@isdg.net Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations On 7/26/2020 11:29 AM, Hector Santos wrote: > Dave, for a number of years of practice, depending in the system or > service, users have been provided with trust-related decisions . Do > you need real examples? There is a difference between providing a signal, versus its getting received and use. Please provide objective data that these signals are being perceived and used effectively by end users. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ 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
On 7/26/2020 2:34 PM, Dave Crocker wrote: On 7/26/2020 11:29 AM, Hector Santos wrote: Dave, for a number of years of practice, depending in the system or service, users have been provided with trust-related decisions . Do you need real examples? There is a difference between providing a signal, versus its getting received and use. Please provide objective data that these signals are being perceived and used effectively by end users. Dave, I made a mistake to preempt the remaining comment by saying "Do you need real examples?" I thought I had removed it. It was rude. Sorry. Please read the remaining part in my previous message with my input explaining how GMAIL provides Trust-Related decision options to the layman user mail reader. There is a lot more to this and I need to go. I think you are correct in suggesting the user has no input in the protocols are are looking for. Its the deterministic vs subjective/learning/heuristics protocols issue again. In reality, we don't have the latter (IETF public domain standard for a non-deterministic filtering engine). Unless we want to include SpamAssasin as the Default EmailCore AVS Engine, it has been a long time missing, desirable part of the total picture. With that engine, users would be a natural part of the equation. Unfortunately, we are not there. But with the former, I always thought these deterministic protocols were targeted for unsolicited, anonymous transactions where only the AUTHOR DOMAIN, the self-signing domain, is the only trusted source. Not the user or even the sender unless IFF there is an Author::Sender association established. Have a good day, off to relax at the safe-distancing pool. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ 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/26/2020 11:29 AM, Hector Santos wrote: Dave, for a number of years of practice, depending in the system or service, users have been provided with trust-related decisions . Do you need real examples? There is a difference between providing a signal, versus its getting received and use. Please provide objective data that these signals are being perceived and used effectively by end users. d/ -- 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 7/26/2020 12:12 PM, Dave Crocker wrote:> My comment was about observable behavior, not philosophical anything. The issue isn't about was is available to users, but what they actually do. Behavior. Dave, for a number of years of practice, depending in the system or service, users have been provided with trust-related decisions . Do you need real examples? Gmail moves spam into Spam box. If you user do not look into their spam box, their inaction is used to give spam weight to false positives. If the user is looking for something, finds it in the spam box, it will see something like this: "What is this message in spam? (specific or vague reason)" "REPORT NOT SPAM" Clicking "REPORT NOT SPAM" it doesn't guarantee it will be moved to an area you can see it. It's been reported as lost, you just can't find it. So it is sent again. The next time another message of the same type is received, it will also be placed in the spam box but this time it says: "What is this message in spam? it is similar to messages identified as spam in past" "REPORT NOT SPAM" Clicking "REPORT NOT SPAM" it doesn't guarantee the next transaction will not be moved into the spam box the next time. There are properly other behaviors the user must make before the message source is "white listed." I am not sure if we can model this behavior based on the different ways it may be done, but let me outline what I have observed with users: - May never check spam box - May check if expecting a message unexpectedly delayed. - Ignore it, it gets weighted as spam. - Click Report not Spam. Cross finger you can see it in-box. - Next similar messages are still moved to spam box It is the last behavior that is concerning because when you are dealing with layman users who may see an message in a spam box but leave it there, it appears GMAIL will keep adding weight to it as a spam, negatively impacting the source identities of the mail. In the end, the positive of SPAM box are lost because now you are forcing the user to scrutinize the Spam Box opening the door to reading and accidental clicks. if REPORT NOT SPAM does not clear it up, there is even more confusion for the purpose of that button or any similar AI learning logic that may be employed. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ 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
Recipient domains determine what messages they will accept or reject.Fairness and precedence are not necessarily applicable.I suggest that the DMARC standards track be placed on hold for at least a year. It is not clear to me, from this group's membership, that DMARC implementers feel an urgent need for standard status, so a delay should be tolerable to them.A Mailing List Protection WG should be formed to develop his ideas into an informational or experimental RFC. Then that RFC can be promoted to see if it wins over any current users of DMARC Sent from my Verizon, Samsung Galaxy smartphone Original message From: Dave Crocker Date: 7/26/20 9:50 AM (GMT-05:00) To: Brandon Long Cc: IETF DMARC WG , Dotzero Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations On 7/21/2020 1:42 PM, Brandon Long wrote: > Stricter validation is not an uncommon addition to protocols over the > last 45 years. If there are examples of adding stricter validation in a way that essentially requires changing the semantics of the payload, in order for the payload to survive, I can't think of any. Not TLS, not DNSSec, not S/MIME or PGP. DMARC essentially enforces a semantic on the From: field as a handling identifier, rather than an author identifier. When activity that has a long history of semantic validity and a continued desire for operation is forced to break the denotational source of authoring information, in order to get the mail delivered, then we are in new territory. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ 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
On 7/26/2020 10:10 AM, Jim Fenton wrote: On 7/26/20 6:42 AM, Dave Crocker wrote: On 7/21/2020 12:32 PM, Dotzero wrote: The original DMARC effort was, in fact, to detect actual cases of spoofing, namely unauthorized use of a domain name by outside actors. Different problem. Actually, part of the effort was to enable Sending domains to identify their own mail that was being sent without aligned DKIM signing or from places not authorized through SPF - in other words, not properly authorized but legitimate, hence feedback loops. As I recall, this was /not/ part of the original purpose of DMARC, which was discussed strictly in terms of mail from bulk senders. What you describe was, rather, the basis for the later use, which is what then started causing problems for mail going through Mediators. Just identifying their own mail their own email that was sent...: Yes, that's always been part of the original purpose of DMARC, and is the purpose of the reporting mechanisms. Yes, Looking over the original I-D posted for DMARC -- which was written after DMARC was already functioning, from work outside the IETF -- I'm unclear where this goal of "identify[ing] their own mail that was being sent without aligned DKIM signing" is clearly explained.(*) Rather, note: 2. Introduction This memo defines Domain-based Message Authentication, Reporting and Compliance (DMARC), a mechanism by which email operators leverage existing authentication and policy advertisement technologies to enable both message-stream feedback and enforcement of policies against unauthenticated email. and 3.1. High-Level Requirements At a high level, DMARC is designed to satisfy the following requirements: o Minimize false positives. o Reduce the amount of successfully delivered phish. (Caveat: None of the text I've excised explicity supports this claimed use. To the extent someone thinks it or any other text in this draft does demonstrate that intended use, please explain how that interpretation is clear from the text in the draft.) d/ (*) https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/00/?include_text=1 -- 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 7/26/20 6:42 AM, Dave Crocker wrote: > On 7/21/2020 12:32 PM, Dotzero wrote: >> >> The original DMARC effort was, in fact, to detect actual cases of >> spoofing, namely unauthorized use of a domain name by outside actors. >> >> Different problem. >> >> >> Actually, part of the effort was to enable Sending domains to >> identify their own mail that was being sent without aligned DKIM >> signing or from places not authorized through SPF - in other words, >> not properly authorized but legitimate, hence feedback loops. > > > As I recall, this was /not/ part of the original purpose of DMARC, > which was discussed strictly in terms of mail from bulk senders. > > What you describe was, rather, the basis for the later use, which is > what then started causing problems for mail going through Mediators. > Just identifying their own mail their own email that was sent...: Yes, that's always been part of the original purpose of DMARC, and is the purpose of the reporting mechanisms. Yes, the reports will contain information on many mediators, but that's just noise in the reports. It also contains information when, for example, the product XYZ marketing department decided to use a new mail sending partner without telling anyone. That's useful. It's the policy mechanism (or more specifically its use by other than transactional domains) that's causing the problem here. -Jim ___ 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
My wording was not careful enough. What I /meant/ was: end-users are not relevant to the /trust-related decision making/ that is the goal of these protection mechanisms. This may be a philosophical theory, but in reality, in lieu of having deterministic mechanisms, we do have mail systems who do allow the user to make these type of trust decisions. If a trust-related question is answered wrong by the user, the true victim is the honest sender. My comment was about observable behavior, not philosophical anything. The issue isn't about was is available to users, but what they actually do. Behavior. d/ -- 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 7/26/2020 7:40 AM, Dave Crocker wrote: My wording was not careful enough. What I /meant/ was: end-users are not relevant to the /trust-related decision making/ that is the goal of these protection mechanisms. This may be a philosophical theory, but in reality, in lieu of having deterministic mechanisms, we do have mail systems who do allow the user to make these type of trust decisions. If a trust-related question is answered wrong by the user, the true victim is the honest sender. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ 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/21/2020 1:42 PM, Brandon Long wrote: Stricter validation is not an uncommon addition to protocols over the last 45 years. If there are examples of adding stricter validation in a way that essentially requires changing the semantics of the payload, in order for the payload to survive, I can't think of any. Not TLS, not DNSSec, not S/MIME or PGP. DMARC essentially enforces a semantic on the From: field as a handling identifier, rather than an author identifier. When activity that has a long history of semantic validity and a continued desire for operation is forced to break the denotational source of authoring information, in order to get the mail delivered, then we are in new territory. d/ -- 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 7/21/2020 12:32 PM, Dotzero wrote: The original DMARC effort was, in fact, to detect actual cases of spoofing, namely unauthorized use of a domain name by outside actors. Different problem. Actually, part of the effort was to enable Sending domains to identify their own mail that was being sent without aligned DKIM signing or from places not authorized through SPF - in other words, not properly authorized but legitimate, hence feedback loops. As I recall, this was /not/ part of the original purpose of DMARC, which was discussed strictly in terms of mail from bulk senders. What you describe was, rather, the basis for the later use, which is what then started causing problems for mail going through Mediators. d/ -- 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 7/20/2020 3:05 PM, Jesse Thompson wrote: 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- ** We have had many complaints from users about the From munging ** My wording was not careful enough. What I /meant/ was: end-users are not relevant to the /trust-related decision making/ that is the goal of these protection mechanisms. They certainly /are/ relevant to the sorting/searching/presentation issues that are disrupted by having mail authored by the same person contain different From: field data. d/ -- 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 7/20/2020 1:44 AM, Alessandro Vesely wrote: 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? No. A specification defines a field of activity. (A sandbox.) Things outside that field are not relevant to the specification, even though they might be highly relevant from a larger perspective. There is a constant desire to have a specification that involves security-related decision-making include the (human) recipient be an actor within the scope of the specification. The first paragraph, quoted above, is a reminder that we need to resist that desire. The second paragraph, quoted above, is a reminder about a specific example of this, namely about the DMARC specification. It acknowledges that, in general, recipients can be deceived, for the specific From: field protection that DMARC provides, the recipient is not a relevant actor. 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. It is expensive and highly risky to create an international standard that relies on such a tenuous hope about future behavior, especially in the face of consistent empirical evidence that it won't happen. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: Agenda requests for Madrid IETF
On Sun 26/Jul/2020 04:00:40 +0200 Dotzero wrote: On Sat, Jul 25, 2020 at 9:48 AM Murray S. Kucherawy wrote: On Fri, Jul 24, 2020 at 12:05 PM Dotzero wrote: I would like to see an agenda item as to whether work around "Display Name" changes are in scope or out of scope for this effort and this working group. It would seem to me that any such efforts are more appropriate for the emailcore working group. A quick read of the current charters suggests to me that it's in scope for neither. That seems to be especially true for emailcore. Do you have such a change to propose? I was hoping for a ruling that such an effort be ruled out of scope for the DMARC effort/working group and further discussions be limited by the Chairs. As "Not Douglas E. Foster" (John Levine) noted, it is a free form field. Although out of scope, I'd still propose that display name abuse be explicitly mentioned in one of the specs as an out-of-scope problem that has to be solved at a different level. DMARC has been intended from the start to mitigate direct domain abuse by 3rd parties. I'm hoping that the working group will make better progress by focusing on issues specific to DMARC and not try boiling the ocean by trying to "fix" all forms of abuse through this effort. Display Name abuse is a broader problem that DMARC simply is not in a position to address. This is especially true as most current implementations are at the MTA and MUA providers are not visible among the participants in this working group. My opinion is that trying to address this problem space in this working group is somewhat like trying to push on a rope. Let me add that, for the sake of Murray's dkim-transform, unlike subject tag and footer additions which only need a couple of bits to be undone, display name removal would require the full original header field, as in a (partial) z= tag. BTW, dkim-transform, along with From: rewriting, using To:, using Author:, and giving up any modifications make for an effective solution of the MLM problem. None of them belongs specifically to DMARC, albeit the spec could mention them. Dkim-transform, in particular, looks like an update to RFC 6376. Yet, it might be practical for this WG to adopt it. Shall we discuss that F2F? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
