From nobody Sat Jun 17 14:39:58 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 B8BF4C15109E for ; Sat, 17 Jun 2023 14:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 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, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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=pass (1024-bit key) header.d=mailchannels.com 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 I-q1mZqcPIEa for ; Sat, 17 Jun 2023 14:39:52 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 43B67C151066 for ; Sat, 17 Jun 2023 14:39:52 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id 38308e7fff4ca-2b203891b2cso26962611fa.3 for ; Sat, 17 Jun 2023 14:39:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.com; s=google; t=1687037990; x=1689629990; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=K4BE3SfZ9yompwHM8PnqFVbjViijBKG7XsC1+VoZErE=; b=DkZphU0385IPG1G3orlb9ms78bw32ImXpB8N/mzTeD+mPy1cAe7G9BQft4bAThVnMl 2gTs/9WLcuMWSrBW9WUYpjpVy8yo0b6iIKwn10ZLAshzldacROIxo41hcoHWzysR/N4n /fD5Oqg+AVfnrg4kta5BLuJ51+chxGYZH9u9o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687037990; x=1689629990; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=K4BE3SfZ9yompwHM8PnqFVbjViijBKG7XsC1+VoZErE=; b=TR5EMl0mS+R+ISTOlPYjR+UTL7ETsrz76nVV9kSjXfsN65+RhP0g0cU+hzRs8rO8bn Z8qTBedHbMK46Lv9iDWRDBggnfCYwPCmcAN40qFT9GVk3o9AJNZU+NDHioA/4E7cGcMr ivBHjPI4BCaXSC+L51ar4ausNgIa0ym35jNoFUyVIrd4g15LRWHNHPuEUN3uHAsE5/5b ugX0k3lKuZbnYkqx+FRDH95Mfr1JSwB9w/AnV2BatiaDTHeessPl11rU43eT/BW/0Lfi hSnrPaEJG/2JE18uuyb+Fxo7mh/6ZNkxzdbcQDfF6/sLlCTo98gzDsem4nlBWGfI4kQA WEtw== X-Gm-Message-State: AC+VfDyHo0hl6nzqjQxP7kRGONvZWMiix760ChYRKqSEKemOfkbvG2qU DSEtohxhW77TSAhjJA2sRq7rLL3LrF2xPmSQJVxMgpYSAVgt6PCZ9Dg= X-Google-Smtp-Source: ACHHUZ5VzKO3W5VyfaddV4JopIvmggFxVICtoNRBZn6b42zcfTXXnkm9fExHLsqxE3GIQXA0934x/k1eDe/baGwW7CQ= X-Received: by 2002:a19:e050:0:b0:4f4:7afe:c36 with SMTP id g16-20020a19e050000000b004f47afe0c36mr3020905lfj.10.1687037989441; Sat, 17 Jun 2023 14:39:49 -0700 (PDT) MIME-Version: 1.0 References: <30BB83B2-B454-41B8-992B-8E2569802D9C@1und1.de> <2817813.dRqVH37e0G@localhost> <25736.57534.195344.782189@fireball.acr.fi> <1ec42959-977a-9ce0-907a-83a5eb2b6ef2@tana.it> <25739.5435.550786.601699@fireball.acr.fi> <25739.33240.127804.524371@fireball.acr.fi> <5d9a0b0f-8777-2494-d779-376c6ab8b37d@tana.it> <7d39aa8e-dacc-05fa-eff1-2cc350d521db@inboxsys.com> <47b8a0c7-6a52-a4ad-e98e-8cb2f881713e@inboxsys.com> <285f2d2e-13fd-7cdc-c816-fba759f0745b@dusatko.org> In-Reply-To: From: Ken Simpson Date: Sat, 17 Jun 2023 14:39:12 -0700 Message-ID: To: Douglas Foster Cc: =?UTF-8?B?SmFuIER1xaHDoXRrbw==?= , dmarc@ietf.org Content-Type: multipart/alternative; boundary="000000000000156cf405fe5a2446" Archived-At: Subject: Re: [dmarc-ietf] 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: Sat, 17 Jun 2023 21:39:56 -0000 --000000000000156cf405fe5a2446 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FWIW, I'd like to chuck my hat in the ring on the side of removing SPF from the next iteration of DMARC. As the operator of an email delivery service with tens of millions of primarily uncontrolled senders on web hosting servers, it would be *great* if domain owners could assert via their DMARC record that receivers should only trust DKIM-signed email. While one option would be to allow the specification within the DMARC record of acceptable authentication methods, removing SPF altogether would be more straightforward. Domain owners constantly struggle to keep their SPF records up to date. Errors are easy to make, and the consequences of a mistake can be grave, particularly for domains that are a frequent target of phishing gangs. At least with DKIM, domain owners can take charge of their authentication rather than delegating any part of it to third parties (for instance, via spf include records). Regards, Ken On Sat, Jun 17, 2023 at 11:25=E2=80=AFAM Douglas Foster < dougfoster.emailstandards@gmail.com> wrote: > In general, message recipients lack the expertise needed to distinguish > between legitimate and fraudulent identities. Most users do not know h= ow > to read message headers or how to make sense of them if shown. Whenour > automated evaluation systems and administrative quarantine cannot resolve > an ambiguity, users cannot be expected to do better with less information= . > Domain-specific tolerance for risk needs to be implemented with > domain-specific policies, but not with end-user discretion. > > DMARC has limited scope. In its purest form, it only blocks > impersonations when the domain has a DMARC policy, the policy specifies > enforcement (quarantine or reject), and the policy is detected correctly > (absence of PSL errors and absence of in-transit changes). Only a subse= t > of domains have a DMARC policy, and only a subset of those domains have > enforcement. So only a small percentage of impersonation attacks can be > protected by DMARC. For that very limited defense to work, domain owners > and evaluators need a high level of confidence in a PASS result. > Eliminating the PSL increases the confidence in PASS even if it creates > some increase in false failures. Eliminating SPF will have the same > effect, and is desirable for the same reason. Our assumption is that > DMARC-enforcing domain owners are highly motivated and will reconfigure a= s > necessary to ensure DMARC PASS results. > > This same logic raises questions about whether relaxed authentication > remains necessary or appropriate. With SPF, relaxed authentication seems > necessary because changing the MailFrom domain to match a desired From > domain is complex. For DKIM, I see no important obstacles which prevent > the signature domain from exactly matching the From domain. > > ARC addresses the one problem that domain owners cannot prevent, which is > forwarding with in-transit changes. > > Evaluators and recipients have a much larger problem. They need to > protect themselves from all impersonation attacks, which DMARC does not > attempt. Their defenses must be implemented within the limits of > information available at evaluation time. If the message has a relevant > DKIM signature but no DMARC policy, the DKIM PASS is still a valid > indication that the message is not impersonated. Similarly, if the > message has no signature but produces SPF PASS with exact alignment, the > SPF PASS result indicates that the message is probably not impersonated. > Conversely, SPF FAIL and SPF NONE service to increase the suspicion of an > impersonation. > > Evaluators use sender authentication to perform a three-way split on > messages: > - Messages from verified and highly trusted senders are allowed to bypass > some or all content filtering. > - Messages from unwanted senders are unconditionally blocked prior to > content filtering. > - Messages from all other senders are accepted if they pass content > filtering. > > The more effective your sender authentication, the less you need perfect > content filtering. Similarly, the more perfect your content filtering, > the less you need optimal sender authentication. > > In summary, your instincts are correct, SPF has a long term role in your > defenses, even if it is not part of the DMARC specification. > > Doug Foster > > On Sat, Jun 17, 2023 at 8:28=E2=80=AFAM Jan Du=C5=A1=C3=A1tko 40dusatko.org@dmarc.ietf.org> wrote: > >> Hi >> >> I would like to know your opinion on the options currently available to >> the system administrator. If it is trying to define a policy that allows >> recipients to authenticate emails, its options are, in my opinion, >> limited. >> - The issue of SPF and cloud systems mentioned, or including over >> networks with mask /8 or /16 is extremely inappropriate >> - It is not possible to set up the enforcement of DKIM signatures >> because DomainKey and its policies are not related to DKIM and there is >> no similar technology for DKIM (ADSP is not used) >> - If I am the administrator of hundreds or thousands of domains, it is >> in my interest to provide the recipient with information about the >> sender's authentication options. For example, all emails use DKIM, all >> emails use ARC, all emails use SPF ... and if not, you can discard them. >> But I do not have this option with DMARC. >> I understand that this is in the middle of what DMARC2 is supposed to >> address. But could there be a possibility for the DMARC2 record >> administrator to define a policy for domains and provide relevant >> information for recipients? It is the recipient's decision whether to do >> this verification, but it is also the sender's decision to offer this >> information. Unfortunately, at this point, either the signature is >> valid, or wrong, or it is not. If it is not possible to accept the >> e-mail, but the recipient does not have the option of verifying whether >> the sender's domain enforces this signature. It is similar with SPF. And >> DMARC2 seems to me to be a good place for these definitions. But I would >> like to avoid of forced removal of SPF, please let it for administrator >> decision. >> >> Regards >> >> Jan >> >> Dne 16. 6. 2023 v 13:28 Sebastiaan de Vos napsal(a): >> > The need for separate DKIM failure codes to be able to separate >> > between in-transit changes and public key errors is more than just >> > valid and I don't consider SPF worthless in general, but I just find >> > it disturbing how the obviously misplaced confidence in SPF currently >> > weakens the whole DMARC standard. >> > >> > Is it not in our best interest to encourage and motivate in particular >> > the less sophisticated senders to use the higher confidence mechanisms= ? >> > >> > >> > On 16.06.23 13:02, Douglas Foster wrote: >> >> RFC 7489 takes 8 different authentication mechanisms and lumps them >> >> into a single PASS result: >> >> DKIM or SPF, each with up to four types of alignment: same domain, >> >> parent->child, child->parent, and sibling->sibling >> >> >> >> These eight mechanisms all provide some level of confidence that the >> >> message is not impersonated, but they do not provide an equal level >> >> of confidence. >> >> >> >> Unsophisticated senders have little incentive to use the higher >> >> confidence mechanisms because any PASS result is still PASS. The >> >> solution is not to pretend that SPF is worthless, because that is an >> >> overstatement. The solution is to talk about the differences in >> >> confidence provided by the different authentication methods, and note >> >> that evaluators have reason to distrust some of them. That distrust >> >> could cause a weakly authenticated message to be distrusted by some >> >> evaluators. >> >> >> >> Similarly, needs multiple types of FAIL. Since the data indicates >> >> that missing (or invalid) public keys are a significant portion of >> >> all failures, it needs a separate failure code from "normal" failures >> >> which suggest in-transit changes. The DKIM group needs to define the >> >> result code but this group would need to integrate it into our >> >> aggregate reports. >> > >> > >> >> -- >> -- --- ----- - >> Jan Du=C5=A1=C3=A1tko >> >> Tracker number: +420 602 427 840 >> e-mail: jan@dusatko.org >> GPG Signature: https://keys.dusatko.org/E535B585.asc >> GPG Encrypt: https://keys.dusatko.org/B76A1587.asc >> >> _______________________________________________ >> 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 > --=20 Ken Simpson CEO, MailChannels Facebook | Twitter | LinkedIn | Help Center Our latest case study video: watch here! --000000000000156cf405fe5a2446 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FWIW, I'd like to chuck my hat in the ring on the side= of removing SPF from the next iteration of DMARC. As the operator of an em= ail delivery service with tens of millions of primarily uncontrolled sender= s on web hosting servers, it would be=C2=A0great=C2=A0if domain=C2= =A0owners could assert via their DMARC record that receivers should=C2=A0on= ly trust DKIM-signed email. While one option would be to allow the specific= ation within the DMARC record of acceptable authentication methods, removin= g SPF altogether would be more straightforward.

Domain o= wners constantly struggle to keep their SPF records up to date. Errors are = easy to make, and the consequences of a mistake can be grave, particularly = for domains that are a frequent target of phishing gangs.

At least with DKIM, domain owners can take charge of their authenti= cation rather than delegating any part of it to third parties (for instance= , via spf include records).

Regards,
Ken=

On Sat, Jun 17, 2023 at 11:25=E2=80=AFAM Douglas Foster <dougfoster.emailstandards@g= mail.com> wrote:
In general, message recipients lack the expertise = needed to distinguish between legitimate and fraudulent identities.=C2=A0 = =C2=A0 Most users do not know how to read message headers or how to make se= nse of them if shown.=C2=A0 =C2=A0Whenour automated evaluation systems and = administrative quarantine cannot resolve an ambiguity, users cannot be expe= cted to do better with less information.=C2=A0 Domain-specific tolerance fo= r risk needs to be implemented with domain-specific policies, but not with = end-user discretion.

DMARC has limited scope.=C2=A0 In i= ts purest form, it only blocks impersonations when the domain has a DMARC p= olicy, the policy specifies enforcement (quarantine or reject), and the pol= icy is detected correctly (absence of PSL errors and absence of in-transit = changes). =C2=A0 Only a subset of domains have a DMARC policy, and only a s= ubset of those domains have enforcement. So only a small percentage of impe= rsonation attacks can be protected by DMARC.=C2=A0 For that very limited de= fense to work, domain owners and evaluators need a high level of confidence= in a PASS result.=C2=A0 Eliminating the PSL increases the confidence in PA= SS even if it creates some increase in false failures. =C2=A0 Eliminating S= PF will have the same effect, and is desirable for the same reason. =C2=A0 = Our assumption is that DMARC-enforcing domain owners are highly motivated a= nd will reconfigure as necessary to ensure DMARC PASS results. =C2=A0
<= br>This same logic raises questions about whether relaxed authentication re= mains necessary or appropriate.=C2=A0 With SPF, relaxed authentication seem= s necessary because changing the MailFrom domain to match a desired From do= main is complex. =C2=A0 For DKIM, I see no important obstacles which preven= t the signature domain =C2=A0from exactly matching the From domain.
ARC addresses the one problem that domain owners cannot prevent, which is = forwarding with in-transit changes. =C2=A0

Evaluators and recipients= have a much larger problem.=C2=A0 They need to protect themselves from all= impersonation attacks, which DMARC does not attempt. =C2=A0 Their defenses= must be implemented within the limits of information available at evaluati= on time. =C2=A0 If the message has a relevant DKIM signature but no DMARC p= olicy, the DKIM PASS is still a valid indication that the message is not im= personated. =C2=A0 Similarly, if the message has no signature but produces = SPF PASS with exact alignment, the SPF PASS result indicates that the messa= ge is probably not impersonated. =C2=A0 Conversely, SPF FAIL and SPF NONE s= ervice to increase the suspicion of an impersonation.

Evaluators use= sender authentication to perform a three-way split on messages:
- Messa= ges from verified and highly trusted senders are allowed to bypass some or = all content filtering.
- Messages from unwanted senders are unconditiona= lly blocked prior to content filtering.
- Messages from all other sender= s are accepted if they pass content filtering.

The more effective yo= ur sender authentication, the less you need perfect content filtering. =C2= =A0 Similarly, the more perfect your content filtering, the less you need o= ptimal sender authentication.

In summary, your instincts are correct= , SPF has a long term role in your defenses, even if it is not part of the = DMARC specification.

Doug Foster=C2=A0 =C2=A0

On= Sat, Jun 17, 2023 at 8:28=E2=80=AFAM Jan Du=C5=A1=C3=A1tko <jan=3D40dusatko.org@= dmarc.ietf.org> wrote:
Hi

I would like to know your opinion on the options currently available to the system administrator. If it is trying to define a policy that allows recipients to authenticate emails, its options are, in my opinion, limited.=
- The issue of SPF and cloud systems mentioned, or including over
networks with mask /8 or /16 is extremely inappropriate
- It is not possible to set up the enforcement of DKIM signatures
because DomainKey and its policies are not related to DKIM and there is no similar technology for DKIM (ADSP is not used)
- If I am the administrator of hundreds or thousands of domains, it is
in my interest to provide the recipient with information about the
sender's authentication options. For example, all emails use DKIM, all =
emails use ARC, all emails use SPF ... and if not, you can discard them. But I do not have this option with DMARC.
I understand that this is in the middle of what DMARC2 is supposed to
address. But could there be a possibility for the DMARC2 record
administrator to define a policy for domains and provide relevant
information for recipients? It is the recipient's decision whether to d= o
this verification, but it is also the sender's decision to offer this <= br> information. Unfortunately, at this point, either the signature is
valid, or wrong, or it is not. If it is not possible to accept the
e-mail, but the recipient does not have the option of verifying whether the sender's domain enforces this signature. It is similar with SPF. An= d
DMARC2 seems to me to be a good place for these definitions. But I would like to avoid of forced removal of SPF, please let it for administrator decision.

Regards

Jan

Dne 16. 6. 2023 v 13:28 Sebastiaan de Vos napsal(a):
> The need for separate DKIM failure codes to be able to separate
> between in-transit changes and public key errors is more than just > valid and I don't consider SPF worthless in general, but I just fi= nd
> it disturbing how the obviously misplaced confidence in SPF currently =
> weakens the whole DMARC standard.
>
> Is it not in our best interest to encourage and motivate in particular=
> the less sophisticated senders to use the higher confidence mechanisms= ?
>
>
> On 16.06.23 13:02, Douglas Foster wrote:
>> RFC 7489 takes 8 different authentication mechanisms and lumps the= m
>> into a single PASS result:
>> DKIM or SPF, each with up to four types of alignment:=C2=A0 same d= omain,
>> parent->child, child->parent, and sibling->sibling
>>
>> These eight mechanisms all provide some level of confidence that t= he
>> message is not impersonated, but they do not provide an equal leve= l
>> of confidence.
>>
>> Unsophisticated senders have little incentive to use the higher >> confidence mechanisms because any PASS result is still PASS.=C2=A0= The
>> solution is not to pretend that SPF is worthless, because that is = an
>> overstatement.=C2=A0 =C2=A0The solution is to talk about the diffe= rences in
>> confidence provided by the different authentication methods, and n= ote
>> that evaluators have reason to distrust some of them.=C2=A0 =C2=A0= That distrust
>> could cause a weakly authenticated message to be distrusted by som= e
>> evaluators.
>>
>> Similarly, needs multiple types of FAIL.=C2=A0 =C2=A0Since the dat= a indicates
>> that missing (or invalid) public keys are a significant portion of=
>> all failures, it needs a separate failure code from "normal&q= uot; failures
>> which suggest in-transit changes.=C2=A0 The DKIM group needs to de= fine the
>> result code but this group would need to integrate it into our >> aggregate reports.
>
>

--
-- --- ----- -
Jan Du=C5=A1=C3=A1tko

Tracker number: +420 602 427 840
e-mail:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0jan@dusatko.org
GPG Signature:=C2=A0 https://keys.dusatko.org/E535B585.asc=
GPG Encrypt:=C2=A0 =C2=A0 https://keys.dusatko.org/B76A1587.asc=

_______________________________________________
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


--

Ken Simpson

CEO, MailChannels


Facebook= =C2=A0| =C2=A0Twitter =C2=A0| =C2=A0LinkedIn | =C2=A0Help Center

Our latest case stu= dy video: watch here!
--000000000000156cf405fe5a2446--