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 <barryle...@computer.org> 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 considerations discussed > in [RFC7960] and in the Interoperability Considerations section of > this document [see Section x.x], it is important that Mail Receivers > 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. > END > > — New section — > > ADD > x.x Interoperability Considerations > > As discussed in “Interoperability Issues between DMARC and Indirect > Email Flows [RFC7960], use of p=reject can be incompatible with and > cause interoperability problems to indirect message flows such as > “alumni forwarders”, role-based email aliases, and mailing lists > across the Internet. > > Even a domain that expects to send only targeted messages to > account holders — a bank, for example — could have account > holders using addresses such as jo...@alumni.example.edu (an > address that relays the messages to another address with a real > mailbox) or finance@association.example (a role-based address that > does similar relaying for the current head of finance at the > association). When such mail is delivered to the actual recipient > mailbox, it will necessarily fail SPF checks, as the incoming > IP address will be that of example.edu or association.example, and > not an address authorized for the sending domain. DKIM signatures > will generally remain valid in these relay situations. > > It is therefore critical that domains that publish p=reject > MUST NOT rely solely on SPF, and MUST apply valid DKIM signatures > to their messages. > > Domains that have general users who send routine email are > particularly likely to create interoperability issues if they > publish p=reject. For example, domains that serve as mailbox hosts > and give out email addresses to the general public are best advised > to delay adoption of p=reject until the authentication ecosystem > becomes more mature and deliverability issues are better resolved. > > In particular, if users in p=reject domains post messages to > mailing lists on the Internet, those messages can cause operational > problems for the mailing lists and for the subscribers to those > lists, as explained below and in [RFC7960]. > > It is therefore critical that domains that host users who might > post messages to mailing lists SHOULD NOT publish p=reject. > Domains that choose to publish p=reject SHOULD implement > policies that their users not post to Internet mailing lists. > > As noted in [Section 5.8], receiving domains need to apply more > analysis than just DMARC evaluation in their disposition of > incoming messages. An example of the consequences of honoring > p=reject without further anaysis is that rejecting messages that > have been relayed by a mailing list can cause your own users to > have their subscriptions to that mailing list cancelled by the > list software’s automated handling of such rejections — it looks > to the list manager as though the recipient’s email address is no > longer working, so the address is automatically unsubscribed. > > It is therefore critical that receiving domains MUST NOT reject > incoming messages solely on the basis of a p=reject policy by > the sending domain. Receiving domains must use the DMARC > policy as part of their disposition decision, along with other > knowledge and analysis. > > Failure to understand and abide by these considerations can cause > legitimate, sometimes important email to be rejected, can cause > operational damage to mailing lists throughout the Internet, and > can result in trouble-desk calls and complaints from your own > employees, customers, and clients. > END > > > ----------------------------------------------------------------------------- > > _______________________________________________ > 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
