Re: [dmarc-ietf] Another p=reject text proposal
FWIW I think this language is an improvement over the prior language but I would like to point out two concerns: 1) Specifying receivers with "MUST NOT reject" in Section 8.6 "Interoperability Considerations" presumably to to downgrade a p=reject to quarantine with does carry new security risk. I note that "other knowledge and analysis" is not defined and there may be a temptation to blindly do downgrades. I believe the document needs to note that new risk in that Section 5.8 "Policy Enforcement Considerations" [1] and Section 11 "Security considerations" so that receivers apply the downgrade in secure way. Section 5.8 already does note risk for the immediate recipients as says "it may increase the likelihood of accepting abusive mail" however it should note risk in forwarded flows and the risk to those recipients. In particular I'm worried about SPF upgrade attacks as described by Liu et. al. [2]. Here an adversarial senders may exploit overly broad SPF policies of victim domain that permit SPF upgrade as noted Section 4.2.2 in plus relaxed DMARC to enable DMARC From header spoofing. The paper notes that some receivers today may relax DMARC as a user setting to improve deliverability i.e. permit downgrading a p=reject enforcement to p=quarantine in Section 4.2.3 and another setting to forward messages as described in Section 4.3.1. Liu et al. was able to demonstrate sending spoofed state.gov emails that passed DMARC at the receiver despite a "p=reject" policy using those steps as described in Section 5. Presumably receivers that then more broadly apply DMARCbis p=reject downgrade may inadvertently create a new vector for SPF upgrade attacks. Some suggestions are for receivers to be cautioned against doing p=reject downgrades if they don't validate participation by the forwarding recipient. Another is if DMARCbis adopts some scoped authentication, is for domains to deploy a DMARC DKIM-only authentication policy. This not some academic issue and the spammers are very aware of SPF upgrade attack technique i.e. looking for ways to exploit it. We've seen significant scaling of this type of attack over the past two years or so. 2) The proposed language calls out "“alumni forwarders”, role-based email aliases, and mailing lists" for consideration by receivers. How should receivers be aware that traffic failing authentication should be reconsidered? Mailing-lists sometimes uses RFC2919 List-id headers. Can Section 5.8 [1] call out more strongly the application of those List-id headers? Can something be done so that receivers can identify the other scenarios e.g. role-based email aliases and alumni-forwarders? [1] DMARCbis: https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-dmarcbis-28 [2] Liu, Enze, et al. "Forward Pass: On the Security Implications of Email Forwarding Mechanism and Policy", 8th IEEE European Symposium on Security and Privacy, 2023, https://arxiv.org/abs/2302.07287 -Wei On Thu, Jul 6, 2023 at 7:55 AM Barry Leiba wrote: > I had some off-list discussions with Seth, who was very much against > my original proposed text, and he suggested an alternative > organization that would be more palatable to him. I've attempted to > set that out below. The idea is to remove the normative requirements > about using p=reject from Sections 5.5.6 and 5.8, and instead put a > broader discussion of the issues, along with the normative > requirements, into a new "Interoperability Considerations" section. > This makes it explicitly clear that any MUST/SHOULD stuff with regard > to using and honoring p=reject is an issue of interoperating with > existing Internet email features. I can accept that mechanism also, > and so, below is my attempt at writing that proposal up. > > Barry > > > - > > — Section 5.5.6 — > > ADD >In making this decision it is important to understand the >interoperability issues involved and problems that can result for >mailing lists and for deliverability of legitimate mail. Those >issues are discussed in detail in the Interoperability >Considerations section [see Section x.x]. > END > > — Section 5.8 — > > OLD >Mail Receivers MAY choose to accept email that fails the DMARC >mechanism check even if the published Domain Owner Assessment Policy >is "reject". In particular, because of the considerations discussed >in [RFC7960], it is important that Mail Receivers SHOULD NOT reject >messages solely because of a published policy of "reject", but that >they apply other knowledge and analysis to avoid situations such as >rejection of legitimate messages sent in ways that DMARC cannot >describe, harm to the operation of mailing lists, and similar. > NEW >Mail Receivers MAY choose to accept email that fails the DMARC >mechanism check even if the published Domain Owner Assessment Policy >is "reject". In particular, because of the consid
[dmarc-ietf] How did DMARC go wrong, and how does our document fix it?
Murray recently observed, correctly, that something went horribly wrong with the DMARC rollout, because it caused (continues to cause) many safe and wanted messages to be blocked. My assessment was in a recent post: Something about the language of RFC 7489 caused implementers to focus on blocking individual messages, when the appropriate use of DMARC is to identify and investigate potentially malicious sources. The "message blocking" approach violates the interests of the users it is intended to protect: - An attacker sends 10 messages that maliciously impersonates a big bank. With help from DMARC p=reject, the evaluator blocks them all. The attacker follows up with 10 messages that maliciously impersonate a major university. The stupid evaluator says, "p=none means no problem here". The message is accepted and the user is harmed because the evaluator learned nothing from blocking the successful attack. Consider a variant of the above: The attacker never impersonates a big bank with p=reject, it only impersonates big universities with p=none. The foolish evaluator blocks nothing because it only acts on domains with p=reject. Again, the user is harmed. And we know the flip side: Safe and wanted messages get blocked because p=reject is enforced without investigation against mailing lists and other traffic. Security theory says that ANY unauthenticated message COULD be a malicious impersonation, and worthy of investigation. Experience says that malicious impersonations are a small percentage of all unauthenticated messages. As a result, the appropriate response to an authentication failure is to investigate, not to block. I don't know exactly how to communicate the difference between message blocking and sender investigation in DMARCbis, but I sure hope that we will try. Doug Foster ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Eliminating From Munging from this list
We have two tracks that we can pursue for eliminating From munging from this list: They can be pursued in parallel: Track 1: Downgrade Request We identify the small number of domains and subscribers who participate from p=reject domains, and consequently have their submissions munged. We develop a document which explains all the reasons why p=reject is a bad idea because of its impact on mailing lists. We ask the p=reject participants to ask their domains to change their DMARC status from p=reject to p=none. We see if the participants are willing to submit the request. We evaluate responses from those domains. This track could have been done a long time ago. Track 2: Exception Request 1) We fix our incoming filtering so that all submissions have verified identities. This is much easier for a list like this one than for a general mailstream. 2) We implement conditional munging. 3) We document and explain the list's operating practices, to include: - The techniques we use to achieve 100% identity verification - The message changes made by the list, with a special emphasis on the security benefits of forcing all body content to text mode. - Other content controls, such as attachment policy. - All of the ways that list messages can be distinguished from all other messages, so that a filtering exemption can be applied successfully Then we explain that because of these controls, DMARC enforcement is not needed because sender authentication has already been enforced. Because the beneficial content changes, DMARC enforcement at final delivery is actually counter-productive. 4) Finally, we ask all participants to submit an Exception Request to their email policies, to bypass DMARC enforcement for list messages. Our operating practices document is intended as supporting material for the exception request. 5) For any participant that receives a favorable response to his submission request, we skip From munging on messages sent to that that domain. Track 2 requires actual "Internet Engineering" - We SHOULD be doing 100% sender authentication. Undertaking the effort will identify technical obstacles that need to be overcome. The technical obstacles may be different for different list types. The effort will almost certainly identify authentication techniques that are effective for authentication purposes but not currently configured as an A-R or ARC authentication result. - We SHOULD provide better documentation of our operating practices. Undertaking the effort will provide a model for other lists to follow. Track 2 benefits: - From munging can be eliminated for a participant with only the cooperation of their domain administration. The solution does not require the cooperation of any other domains. - Elimination of From munging is potentially available to all participants, even those from p=reject domains - We are not fighting a battle to convince domains to lower their security posture. - Results can be obtained in months, possibly a year, based on development complexity and available resources. We have been trying some version of Track 1 for over a decade, with poor results. Can we please get started on Track 2? Doug Foster On Thu, Jul 13, 2023 at 10:55 AM Barry Leiba wrote: > > The issue is not about lists being second class. What lists do to a > message is a privileged function, because > > modifying a message can be done maliciously as easily as it can be done > innocently. So the real problem > > is that DMARC demoted them from privileged to non-privileged by exposing > the risk inherent in their message > > modifications. Non-privileged parricipants do not have permission to > modify messages that they did not author. > > I do mostly agree with this, and it's a good point. > > Let me note two things: > > (1) As I've said before, telling mailing lists how they might deal > with this situation is out of scope for THIS DOCUMENT. > > (2) Telling mailing lists how they might deal with this situation is > absolutely in scope for this working group. > > Apart from rewriting the From header, which you seem to be presenting > as the only or best thing that mailing lists can do, there are other > solutions that mailing lists could adopt. For example, they could > bounce posts from p=reject domains. They could simply not modify > messages that are posted from p=reject domains. Ale has a proposal > that we will surely discuss at some point that sets up an automated > allow-list system so that receiving domains can adjust based on > information from the mailing list and the subscriber. > > We can and should discuss these and consider an update to RFC 7960, > perhaps as a BCP for mailing list managers about dealing with DMARC. > > In this document, specifying the DMARC protocol, we should say how we > think DMARC should work. I believe that means we need to say, > regardless of who we think will not pay attention, that p=reject is > not intended for domains that give out general-
