From nobody Wed Jun 28 12:44:27 2023 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCA5C14CE51 for ; Wed, 28 Jun 2023 12:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.398 X-Spam-Level: X-Spam-Status: No, score=-4.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b="M4WB8x97"; dkim=pass (2048-bit key) header.d=kitterman.com header.b="B7PavoOD" Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ywpHwP0ztkY for ; Wed, 28 Jun 2023 12:44:22 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E57B2C14CE2B for ; Wed, 28 Jun 2023 12:44:21 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 9D148F802C8; Wed, 28 Jun 2023 15:44:11 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1687981438; h=date : from : to : subject : in-reply-to : references : message-id : mime-version : content-type : content-transfer-encoding : from; bh=SxjbDdSZkMLtOV2x/uh2YsXxJZcten7LEcq+5WoS2nI=; b=M4WB8x97v2Bi1G7cLVCmuYsE243xXqSl+AWJ474bN9SdtT29CbFTmo34fN7v/qpfcU0NJ 9gXRkbVL/iLoP+LDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1687981438; h=date : from : to : subject : in-reply-to : references : message-id : mime-version : content-type : content-transfer-encoding : from; bh=SxjbDdSZkMLtOV2x/uh2YsXxJZcten7LEcq+5WoS2nI=; b=B7PavoODRpZUkyY+L1J8quzqt19vOaehjEge/kwE2DDPy+8vP6aic7HMMR18Iln1IrWkP ymfCepv43f4CwOsq3J4wj9U3uHmmyvFd+oEu9K/UkSa1E+1/i1Uq3cqiDKjgt2YJZGrBSm9 WgPuSr2s8WdPZLlcmkEXBzLW4A3UFVEAzzoHIGPJgq+BCa/Zlgks8DRlO+rJ4urN/iPYmk+ ZPlmteIhcLnOdepjnwZCkGVTp8Ib+ReGCNC4YEfj2mtNmTatix02qO0bYkVIhMJUFVnwbyu HiSHWEK+gCWNEG2zgEow1K84MzChJrNY80N4cIiwBPpgMiN28jnGkVLdVJ+A== Received: from [127.0.0.1] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 613E0F8017C; Wed, 28 Jun 2023 15:43:57 -0400 (EDT) Date: Wed, 28 Jun 2023 19:43:49 +0000 From: Scott Kitterman To: dmarc@ietf.org In-Reply-To: References: <20230623021810.E5F8DF9B3B94@ary.qy> <6495D504.4090809@isdg.net> <839aa10b-f7fa-c7a2-76db-6441189afca2@dusatko.org> <99e1ef2d-053b-8cfe-f369-fa8475d142ae@tana.it> Message-ID: <877A1137-3A55-424A-A9C5-FCCA4F2D5436@kitterman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2023 19:44:25 -0000 I think it's quite relevant=2E The assumption that this is based on is there's a need to specify because = SPF data is not reliable enough for everyone=2E If that premise is correct= (I don't agree with it, but it's a separate issue), then I think telling p= eople that they should use DKIM because it IS reliable, when it's got its o= wn issues isn't a great idea=2E I've been mulling this whole topic over and I think I'm close to having mu= lled it enough to have a useful proposal=2E SPF bad, DKIM good is a gross = over-simplification, but so is if it passed SPF, it's authorized, so go whi= ne at the provider=2E Scott K On June 28, 2023 6:32:41 PM UTC, Barry Leiba w= rote: >I think DKIM replay is largely irrelevant to this discussion (about >the sender specifying which authentication to use), because if that's >your biggest concern with respect to DMARC, then "SPF only" is the >answer=2E "SPF *and* DKIM" is not any better than that=2E > >> You seem to imply that auth=3Ddkim+spf wouldn't be effective against DK= IM reply > >(Assuming you mean "replay"=2E) "SPF and DKIM" does not give any >benefit beyond "SPF only" in this case=2E > >Look, either SPF fails because the message was relayed illegitimately=2E= =2E=2E >=2E=2E=2Eor SPF passes because the replayer used the sender's legitimate >infrastructure to do the replay=2E > >Barry > >On Wed, Jun 28, 2023 at 12:43=E2=80=AFPM Alessandro Vesely wrote: >> >> Thank you for your analysis=2E However, it doesn't touch on DKIM repla= y=2E >> >> I know this topic belongs to the other list=2E Let me briefly recall i= t, if this >> doesn't take too many cycles from core matters: It occurs when a signe= d >> message is replayed by unauthorized hosts to recipients which were not >> originally addressed=2E So, it is one case of your 3rd proposition: In= some >> scenarios, DKIM will pass when SPF fails=2E >> >> You say that it is technically unnecessary to test both because DKIM sh= ould >> always pass when SPF passes (1st proposition)=2E >> >> You claim: >> > But where the harm comes is in cases of mis-configuration, because no= w if >> > *either* of them is misconfigured, the whole thing fails -- neither o= f them >> > serves as a backup for the other; instead, the misconfiguration of ei= ther >> > one causes deliverability problems=2E >> >> >> I agree=2E But what if SPF and DKIM are both configured properly? You= seem to >> imply that auth=3Ddkim+spf wouldn't be effective against DKIM reply, bu= t your >> analysis doesn't cover that case explicitly=2E >> >> Perhaps there are better ways to counter that specific problem, and cer= tainly >> it's not what this WG is tasked to do=2E But, just to make the point, = I think >> it's interesting to know=2E >> >> >> Best >> Ale >> >> >> On Tue 27/Jun/2023 16:24:21 +0200 Barry Leiba wrote: >> > I don't understand how most of your message fits into this discussion= : >> > you're comparing SPF's policy points with DMARC policy=2E we're talk= ing >> > about SPF as an authentication mechanism together with DKIM (not >> > DMARC) as an authentication mechanism=2E=2E=2E and then using those >> > authentication results in DMARC policy evaluation=2E >> > >> > But here: I've said all this before in separate places, so I'll put i= t >> > in one place, here, one more time: >> > >> > Given that SPF and DKIM are both configured properly: >> > 1=2E If SPF passes, DKIM will always pass=2E >> > 2=2E If DKIM fails, SPF will always fail=2E >> > 3=2E In some scenarios, DKIM will pass when SPF fails=2E >> > >> > Therefore, when everything is configured properly, SPF adds no value >> > beyond what DKIM does, and DKIM does add value beyond what SPF does= =2E >> > That's why I am (and others are) arguing that we should remove SPF >> > *from DMARC evaluation*=2E There's no argument that for now, or some= , >> > SPF outside of DMARC still has value=2E >> > >> > What others are arguing is that in the real world, things do get >> > mis-configured, and if DKIM is misconfigured and fails when it >> > shouldn't, SPF adds value by providing a working authentication=2E >> > (And, of course, similarly the other way around, plus DKIM covers som= e >> > cases when messages are relayed or forwarded=2E) That speaks for "SP= F >> > *or* DKIM"=2E >> > >> > But "SPF *and* DKIM" -- requiring *both* to pass -- is technically >> > unnecessary at best, because of (1) above: DKIM should always pass >> > when SPF passes=2E But where the harm comes is in cases of >> > mis-configuration, because now if *either* of them is misconfigured, >> > the whole thing fails -- neither of them serves as a backup for the >> > other; instead, the misconfiguration of either one causes >> > deliverability problems=2E DMARC is damaged by requiring an >> > authentication situation that is unnecessary when things are properly >> > configured, and that is more fragile than what we've been using, more >> > susceptible to configuration errors than we've seen before=2E >> > >> > And I'm afraid that people will use it preferentially, *thinking* tha= t >> > it provides better "security" -- surely, double authentication is >> > better than single, no? >> > >> > No=2E >> > >> > Barry >> > >> > On Tue, Jun 27, 2023 at 6:36=E2=80=AFAM Alessandro Vesely wrote: >> >> >> >> On Mon 26/Jun/2023 20:13:53 +0200 Barry Leiba wrote: >> >>> I'm saying I don't want "and" to be an option, because I think it's >> >>> damaging to DMARC=2E There is no reason anyone should ever want to= say >> >>> that, and providing the option asks for misconfigurations because >> >>> people think it's somehow "more secure"=2E It's not more secure=2E= It >> >>> would be very bad for deliverability of legitimate mail and would >> >>> provide no additional security=2E It would be a terrible mistake= =2E >> >> >> >> >> >> I've been sporting spf-all for years, and seldom experienced bounces= , mostly >> >> due to misconfigured secondary MXes=2E Out of 39 domains whose post= s to this >> >> list in the past year are still in my inbox, 14 have spf-all=2E So,= while I'm >> >> not the only one, not many published -all even though it may seem to= be somehow >> >> more secure=2E >> >> >> >> I think it can be worth to compare SPF and DMARC=2E Another sender = policy a >> >> decade and an authentication method after=2E What adoption, what hy= pe=2E >> >> >> >> Both policies ask receivers to reject a domain identifier in some ca= ses=2E RFC >> >> 7208 explicitly suggests to consider whitelisting (Appendix D)=2E D= MARC provides >> >> for overrides but is less clear about how to handle exceptions=2E A= fter SPF >> >> broke forwarding, the reaction was split between some changing ident= ifier and >> >> turning to ~all; after DMARC broke mailing lists, between changing i= dentifier >> >> and not altering messages=2E In my limited experience, the ratio se= ems to be >> >> higher for DMARC than SPF, but I may be wrong=2E >> >> >> >> In theory, domains that currently have a strict DMARC policy and spf= -all, 6 of >> >> the above, should have their messages blocked when either method fai= ls, up to >> >> changing identifiers=2E Why would it be so bad for deliverability t= o >> >> additionally require DMARC alignment, which is the difference betwee= n that and >> >> the "and"? >> >> >> >> And, it seems to me that an ESP not having a bloated SPF record coul= d stop a >> >> good deal of DKIM replay by resorting to auth=3Ddkim+spf=2E Besides= collateral >> >> deliverability problems, why wouldn't that work? >> >> >> >> Wht would "and" damage DMARC more than -all damaged SPF? >> >> >> >> I hope we can discuss detailed criticism rather than vague ostracism= =2E >> >> >> >> >> >> Best >> >> Ale >> >> -- >> >> >> >> >> >> >> >> >> >> >> > >> > _______________________________________________ >> > dmarc mailing list >> > dmarc@ietf=2Eorg >> > https://www=2Eietf=2Eorg/mailman/listinfo/dmarc > >_______________________________________________ >dmarc mailing list >dmarc@ietf=2Eorg >https://www=2Eietf=2Eorg/mailman/listinfo/dmarc