Re: [dmarc-ietf] Another p=reject text proposal
On Sat, Aug 12, 2023, at 11:48 AM, John Levine wrote: > It appears that Jesse Thompson said: > >> This of course requires that the recipient SMTP server can't simply > >> reject the incoming email after the MAIL FROM because SPF checks do > >> not match, they actually need to receive the email so they can check > >> ARC and DKIM headers... > > > >During my 19 year career we used software built by Ned Freed. It was > >perfectly capable of evaluating full content (as well as > >integrating with 3rd party evaluation software) and return an appropriate > >SMTP response after DATA. Why is it still so difficult? > > I am in yet another argument with a guy who is complaining that he's > not getting forwarded mail, I point out that he's rejecting on SPF > failure so that's not a bug, it's what he has told his system to do, > and he insists it's my fault. For some reason this attitude is > unusually common in mail systems in central Europe. The guy presumably rejects based on SPF during MAIL FROM, right? Rejecting due to DMARC missing SPF alignment would need to wait until DKIM alignment and other factors are known would need to occur after DATA. Sounds like this could be spelled out as a best practice, if it isn't. > To reiterate the obvious, you can't do DMARC without processing the > entire message during the SMTP session at least enough to check the > DKIM signatures. No sensible mail system rejects on SPF failure (other > than bare -all for no mail), because the error rate is so huge. > > A very long time ago people tried to minimize the work in the SMTP > daemon because there were small fixed size connection tables and on > systems without shared libraries, many copies of the daemon could > cause a lot of swapping. These days the connection table never fills > up, my SMTP daemon uses about 30 shared libraries, and my decade old > server can handle 100 connections and barely notices the load. So, > yeah, you can do it all in the SMTP daemon and in practice everyone > does now. I get that there is a lot of legacy code to support which will take forever to change. If it's a matter of requiring increased memory overhead (etc) to get the desired result of being able to consider complete context before issuing the most appropriate SMTP response after DATA, it is technically possible today and is in the receiver's best interest to invest in the additional cost of doing it. Another best practice? I suppose that if per-RCPT considerations are factored into the SMTP response after DATA, it implies that senders will be able to achieve the best interpretation of SMTP response messages by sending to a single recipient per transaction (which sounds like is needed for some of the potential implementations for the "identification of the RCPT TO" for fixing DKIM Replay) Jesse___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Proposal for auth policy tag in draft-ietf-dmarc-dmarcbis
I've also tried rolling up the comments in this thread as well. Below is the result: -Wei = 1. Introduction, 3rd paragraph insert after first sentence: In addition, the choice of permitted authentication methods, SPF or DKIM, method MAY be explicitly specified, potentially to restrict the supported authentication methods. 4.3 Authentication Mechanisms append: Domain Owners and PSOs MAY explicitly specify the supported authentication methods via the OPTIONAL auth tag. The value is a colon ':' separated list of supported authentication methods. The order of the list is not significant, and unknown methods are ignored. An aligned passing result for any listed method indicates a DMARC pass. An empty list of methods is a syntax error. If auth is unspecified, the default is "spf:dkim" and both DKIM and SPF authentication methods are supported. 5.3 General Record Format insert: auth: (colon-separated plain-text list of dmarc-methods; OPTIONAL; default is "spf:dkim") Indicates the supported authentication methods. The order of the list is not significant and unknown methods are ignored. Possible values are as follows: dkim: Authenticate with DKIM spf: Authenticate with SPF An empty list of methods is a syntax error. If any listed method passes and is aligned, then DMARC passes. 5.4. Formal Definition insert: dmarc-method = "dkim" / "spf" dmarc-auth = dmarc-method *(*WSP ":" *WSP dmarc-method) Tag Name Value Rule auth. dmarc-auth On Mon, Aug 7, 2023 at 2:30 PM Murray S. Kucherawy wrote: > Fine with me, just wanted to ask the question. > > -MSK, hatless > > On Mon, Aug 7, 2023 at 1:48 PM Barry Leiba > wrote: > >> Indeed. We can do what we've done in other cases: create a registry >> if/when we add something else later. >> >> Barry >> >> On Mon, Aug 7, 2023 at 4:11 PM Scott Kitterman >> wrote: >> > >> > >> > >> > On August 7, 2023 7:47:03 PM UTC, "Murray S. Kucherawy" < >> superu...@gmail.com> wrote: >> > >On Sat, Aug 5, 2023 at 1:09 PM Tim Wicinski >> wrote: >> > > >> > >> Based on the ABNF in -28, how about something like this: >> > >> >> > >> >> > >> dmarc-method = "dkim" / "spf" >> > >> >> > >> dmarc-auth = "auth" equals dmarc-method *(*WSP "," *WSP dmarc-method) >> > >> >> > >> >> > >> I think this "should"(*) allow for all permutations but also >> simplifies >> > >> it, and I agree with Barry it should be simpler. >> > >> >> > > >> > >This looks good to me, except to be consistent with DKIM (from which >> this >> > >general syntax was borrowed) I'd suggest: >> > > >> > >* using colon as the separator rather than comma >> > >* WSP and CFWS should follow whatever we did for other tags >> > >* don't allow an empty list; I can't think of any DKIM or DMARC tag >> that >> > >accepts a list and also allows an empty value >> > > >> > >If we think we might add "arc" or something else in the future, do we >> need >> > >a registry of supported methods? If not, we'll have to rev DMARC every >> > >time a new one comes into favor. >> > >> > I think we don't need a registry. Rationale: >> > >> > 1. There is no additional method that's being contemplated (whatever >> ARC is, it's not a first class alternative to SPF or DKIM). >> > >> > 2. Currently, we have text in the specification to describe how to use >> the output of SPF and DKIM for DMARC. I don't think there's much prospect >> any new method wouldn't need something similar. >> > >> > I think a registry would only complicate things and wouldn't actually >> be helpful. >> > >> > Scott K >> > >> > ___ >> > 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 >> > ___ > 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] Proposal for additional Security Considerations for SPF Upgrade in draft-ietf-dmarc-dmarcbis
I've tried to roll up the guidance in this thread in the results below. -Wei = 11.9 Quarantined Forwarded Mail Security Risk When receivers apply the "MUST NOT reject" in Section 8.6 to accept unauthenticated messages as quarantined messages, receivers ought to carefully review how they forward mail traffic to prevent additional security risk. The forwarded mail might be able to obtain SPF or DKIM authentication through the receiver, and thereby obtain a fraudulent DMARC aligned From despite having an associated strong DMARC policy of "p=reject". For SPF, a malicious sender needs two properties to perform such a SPF attack: 1) a receiver that will forward quarantined messages, and 2) the spammer finds a SPF policy that covers the forwarding IPs. Such a sender crafts a message with From header assuming the identity of the domain with the SPF policy and matching MAIL FROM. Consequently the receiver evaluates message authentication and finds that the MAIL FROM does not authenticate but does not reject the message and instead quarantines it. Vulnerable receivers then forward the message to some subsequent receiver with the message taking the authenticated identity of the From header. That forwarding might be under control of the malicious sender perhaps via auto-forwarding or enterprise policy. Receivers need to consider restricting forwarding when the message is SPF unauthenticated. For DKIM, a malicious sender finds a forwarder that re-signs messages with DKIM that lets some malicious email take the identity of the DKIM signer domain. Some forwarders appear to do this for all messages. Other forwarders might do this when the message is modified such as mailing-lists. As with the SPF attack, the malicious sender may be able to create a message with some From header corresponding to the spoofed re-signing domain to obtain DMARC alignment at the receiver. Forwarders that re-sign messages with DKIM ought to consider the reputational and identity risk that it imposes. With ARC [RFC8617], receivers sometimes override their local DMARC results with results found from the ARC-Authentication-Result header to prevent mail from being rejected or quarantined. Malicious senders may target these receivers if that override is done improperly. Hence receivers ought to carefully consider whether they can trust the results passed in the ARC-Authentication-Results as they are provided by the forwarder without any guarantee they are correct. SPF, DKIM and ARC forwarding attacks and other considerations are discussed further in Liu et. al. [1]. [1] Liu, Enze et al. "Forward Pass: On the Security Implications of Email Forwarding Mechanism and Policy", Proceedings of the 8th IEEE European Symposium on Security and Privacy, 2023. On Sun, Aug 6, 2023 at 1:46 PM Scott Kitterman wrote: > That reads to me as guidance for DMARC implementers on how to integrate > SPF and DKIM results for the purposes of DMARC. I think that's in scope > for DMARCbis. > > There's a multitude of ways people can screw these things up and we won't > be able to cover them all. The guidance needs to be somewhat high level. > > One of my favorites is a case I was asked to investigate where an ESP had > transmitted a clearly forged email for one of their customers and the > customer wanted to know why DMARC hadn't protected them, even though they > had a p=reject policy. > > What happened was that the ESP received a DMARC fail email from an > unrelated mail server that also had a valid ARC signature, so instead of > rejecting the message, they allowed the ARC result to override the DMARC > policy and accepted it. Then they relayed it to the final destination > (which in the same domain as the From domain - which was owned by their > customer). There's all kinds of things people can do to mess this up. I > don't think it's obscure that one should only believe ARC results from > trusted sources, but there we were. > > Scott K > > On August 6, 2023 8:07:31 PM UTC, Wei Chuang 40google@dmarc.ietf.org> wrote: > >I don't think having this language is saying you can't do SPF. Rather > this > >is about preventing new spoofing attacks on DMARC aligned identity. In > >particular where previously this attack was not possible on forwarders > that > >honored the p=reject policy, now that they will downgrade to quarantine, > it > >opens a new vector that should be reviewed to prevent this attack. I > >propose this because I've seen the forwarding attack with SPF on ups.com. > >The Liu et. al. paper notes that they were able to spoof the From header > >government e.g. state.gov, financial and legal companies with SPF. You > >noted that it's feasible with DKIM too. The RFC should ask forwarders to > >do this review when they p=reject downgrade otherwise it does add systemic > >risk to the DMARC protected From identity. > > > >-Wei > > > >On Sun, Aug 6, 2023 at 11:38 AM Scott Kitterman > >wrote: > > > >> On Sunday, August 6, 2023 2:10:35 PM
[dmarc-ietf] Messages from the dmarc list for the week ending Sun Aug 13 06:00:03 2023
Count| Bytes | Who ++--- 24 ( 100%) | 187014 ( 100%) | Total 4 (16.7%) | 45854 (24.5%) | Wei Chuang 4 (16.7%) | 27867 (14.9%) | Scott Kitterman 4 (16.7%) | 23388 (12.5%) | Alessandro Vesely 3 (12.5%) | 15572 ( 8.3%) | John Levine 2 ( 8.3%) | 19709 (10.5%) | Murray S. Kucherawy 2 ( 8.3%) | 11853 ( 6.3%) | Hector Santos 2 ( 8.3%) | 11009 ( 5.9%) | Barry Leiba 1 ( 4.2%) | 12794 ( 6.8%) | Jesse Thompson 1 ( 4.2%) | 10768 ( 5.8%) | Douglas Foster 1 ( 4.2%) | 8200 ( 4.4%) | Tim Wicinski ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
