Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Neil Anuskiewicz]

> On Oct 28, 2023, at 5:01 AM, Alessandro Vesely  wrote:
> 
> On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote:
>>> On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely  
>>> wrote:
>>> On Fri 27/Oct/2023 12:34:11 +0200 John Levine wrote:
 If there isn't a consensus to do a DKIM-only feature, which seems to be 
 the case, I agree, wrap up the few minor editorial issues and we're done.
>>> 
>>> If we add the feature, we should in any case exemplify how to fix SPF, 
>>> saying that doing so is safer, at least until all DMARC software has 
>>> acquired the new feature.  As the addition would be understood as a 
>>> response to the known vulnerability, it will likely be spread.
>>> 
>>> As many of us consider it cleaner to have DMARC based on DKIM only, having 
>>> that possibility as an option is a first step in that direction anyway.  
>>> The thesis that DKIM is enough has been opposed but the only cases where 
>>> SPF saves the day seem to be software bugs.  The DKIM-only feature would 
>>> allow to probe that thesis, which fixing SPF records would not.
>> 
>> What do we know now that we didn't know the last time we decided not to go 
>> DKIM only?  I'd argue there's nothing and endless relitigation of issues 
>> like this is making it impossible to actually accomplish what we're 
>> chartered to accomplish.
> 
> 
> You're the only one strongly opposing the idea, AFAICS, and I still don't 
> know why.
> 
> 
>> Let's either focus and finish or give up and close the group.
> 
> 
> Even if we don't add the feature, we should address the vulnerability. 
> Currently there is only a bullet in Section 4.8, Organizational Domain 
> Discovery, saying:
> 
>* The domain found in the RFC5321.MailFrom header if there is an SPF
>  pass result for the message being evaluated.
> 
> We need to add a subsection in Security Consideration, discussing an example 
> of an include mechanism with a neutral qualifier and its effect on DMARC 
> outcome; that is, how that avoids spurious authentications.
> 
> The other snippet where SPF qualifiers are discussed is Section 8.1, Issues 
> Specific to SPF.  We could add a reference to the added subsection there.
> 
If explicit language gets us a good portion of the way there. That is forward 
progress for those who support this. Alexandra there must be others not willing 
to go that direction and digging in wil just mean this same conversation 6 
months ago. To keep it neutral the hums should prevail now and those who lost 
this one, remember the battle may be winding down but you have time to provide 
tangible evidence this was a brain dead decision. I’m guess WG members are 
smart and experience quite a bit of neurogenesis (I.e., don’t hold to an idea 
for ego certitude). Even if those who don’t hum hate it, take solace that time 
will show you right if you are right and I doubt anyone humming will hum that 
dissonant song of wrong again. 

If the no hummers are right I hope they humbly re litigate this and change a 
bad policy. Let’s test drive this baby and see if it breaks down out in the 
boonies.
> 
> 
> 
> 
> ___
> 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] DMARCbis way forward: Do we need our session at IETF 118

[Douglas Foster]

On a theoretical level, probabilistic tools like spam assassin will be
predictably wrong some of the time.   Accurate disposition requires audits
and overrides using static rules based on confirmed evidence.  I cannot
find much sympathy for sites that enforce SPF without considering DKIM and
without an audit process.   They are better off ignoring SPF completely.

In the matter of SPF Upgrade attacks, we start from the assumption that SPF
PASS is not reliably true, so neutral is closer to the truth.

Doug

On Sun, Oct 29, 2023, 8:41 PM Tero Kivinen  wrote:

> Murray S. Kucherawy writes:
> > On Sun, Oct 29, 2023 at 12:35 PM Douglas Foster <
> > dougfoster.emailstanda...@gmail.com> wrote:
> >
> > By contrast, the new tag cannot be effective until DMARCbis is
> published
> > and filtering software updated.  This involves years.  Even then,
> domain
> > owners will never have confidence that the new token support has been
> > implemented by all recipient evaluators.
> >
> > At least on its face, this is a big concern.  A domain owner publishing
> "auth=
> > dkim" is going to get varying results as some sites update to software
> > supporting such a tag while others ignore it.  I don't know if the
> potential
> > for some benefit is a desirable trade for the potential for some
> confusion.
>
> Varying meaning, those who implement auth=dkim will get extra
> protection, and those who do not, are left as they are now.
>
> I myself think that adding clear indication that sender always uses
> dkim, and evaluators can rely on that makes the DMARC better, and more
> secure.
>
> And as every DMARC evaluator needs to support DKIM anyways (there is
> no such thing as SPF only DMARC evaluator, both SPF and DKIM are
> mandatory to implement), there is no real difference in complexity for
> evaluators.
>
> > Seems like a slam dunk for SPF neutral.  I said the problem and it's
> > solution needs to be laid out in our document because I am one of
> those
> > who did not understand it as a possible strategy
> >
> > I think I agree.
>
> This will also change the behavior of the receivers. For example
> spamassasin does give more points to SPF_NEUTRAL (around 0.6-0.7) than
> SPF_PASS (-0.001) etc. I would assume other similar software also use
> SPF results similarly.
>
> The reason why SPF_PASS gives only -0.001 is that it is assumed that
> spammers will use their own domain and thus can get SPF records to
> match (DMARC, DKIM and SPF are never meant to work against spammers).
> --
> kivi...@iki.fi
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Alessandro Vesely]

On Sun 29/Oct/2023 21:03:17 +0100 Mark Alley wrote:
Giving this some more thought from the opposite point of view... the benefits 
to an auth=DKIM method in DMARC itself would remove the need for domain owners 
to do SPF tinkering for any upgrade mitigation, and shared mail infrastructure 
where one could potentially be affected by SPF upgrade could instead be 
mitigated by the new tag, but still retain positive SPF authentication.



Hm... diligent SPF settings are still due.  I don't think the ability to sweep 
SPF negligence under DMARC carpet can be considered an upside...



So, theoretically, if we look at it that way, there are a couple of upsides, 
although obviously there is additional added complexity, and as Doug surmised, 
the adaptation of mail filters will take a significant amount of time before we 
see any semblance of ubiquitous adoption.



For added complexity, we need to add an element to the PolicyPublishedType to 
account for auth=.




I'm on the fence currently about the auth= method.



+1, it's role for the next several years seems to be a gauge in the security 
theater.



Best
Ale
--





___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Richard Clayton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In message , Douglas Foster 
writes

>By contrast, the new tag cannot be effective until DMARCbis is published
>and filtering software updated.  This involves years.  

Hard to say ... there is some self-interest here in having shiny new
features (such as they are) and it is argued that pretty much everyone
uses one of a small number of libraries so only a small number of
programmers need to stay up late to make updating possible

Although people did not update software very often 20 years back, fear
of compromises (and the widespread existence of such compromises) means
that updating cycles are far faster than they used to be.

>Even then, domain
>owners will never have confidence that the new token support has been
>implemented by all recipient evaluators.

That of course was one of the reasons for having a version bump ... but
there was no consensus for that. However, careful reading of reports
will tell you whether those evaluators who send reports have updated,
and you can take a view from those

- -- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.7.1

iQA/AwUBZT8VyN2nQQHFxEViEQI4KwCgoq/AfjOOaln5Gz+lGTdC1w2jHG8AoNvY
ojMIxIPArJ94MmA8MhS1tJ0Z
=bOmC
-END PGP SIGNATURE-

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Tero Kivinen]

Murray S. Kucherawy writes:
> On Sun, Oct 29, 2023 at 12:35 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
> 
> By contrast, the new tag cannot be effective until DMARCbis is published
> and filtering software updated.  This involves years.  Even then, domain
> owners will never have confidence that the new token support has been
> implemented by all recipient evaluators.
> 
> At least on its face, this is a big concern.  A domain owner publishing "auth=
> dkim" is going to get varying results as some sites update to software
> supporting such a tag while others ignore it.  I don't know if the potential
> for some benefit is a desirable trade for the potential for some confusion.

Varying meaning, those who implement auth=dkim will get extra
protection, and those who do not, are left as they are now.

I myself think that adding clear indication that sender always uses
dkim, and evaluators can rely on that makes the DMARC better, and more
secure.

And as every DMARC evaluator needs to support DKIM anyways (there is
no such thing as SPF only DMARC evaluator, both SPF and DKIM are
mandatory to implement), there is no real difference in complexity for
evaluators.

> Seems like a slam dunk for SPF neutral.  I said the problem and it's
> solution needs to be laid out in our document because I am one of those
> who did not understand it as a possible strategy
> 
> I think I agree.

This will also change the behavior of the receivers. For example
spamassasin does give more points to SPF_NEUTRAL (around 0.6-0.7) than
SPF_PASS (-0.001) etc. I would assume other similar software also use
SPF results similarly.

The reason why SPF_PASS gives only -0.001 is that it is assumed that
spammers will use their own domain and thus can get SPF records to
match (DMARC, DKIM and SPF are never meant to work against spammers).
-- 
kivi...@iki.fi

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Murray S. Kucherawy]

On Sun, Oct 29, 2023 at 12:35 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> By contrast, the new tag cannot be effective until DMARCbis is published
> and filtering software updated.  This involves years.  Even then, domain
> owners will never have confidence that the new token support has been
> implemented by all recipient evaluators.
>

At least on its face, this is a big concern.  A domain owner publishing
"auth=dkim" is going to get varying results as some sites update to
software supporting such a tag while others ignore it.  I don't know if the
potential for some benefit is a desirable trade for the potential for some
confusion.

Seems like a slam dunk for SPF neutral.  I said the problem and it's
> solution needs to be laid out in our document because I am one of those who
> did not understand it as a possible strategy
>

I think I agree.

-MSK, p11g
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Mark Alley]

Giving this some more thought from the opposite point of view... the
benefits to an auth=DKIM method in DMARC itself would remove the need for
domain owners to do SPF tinkering for any upgrade mitigation, and shared
mail infrastructure where one could potentially be affected by SPF upgrade
could instead be mitigated by the new tag, but still retain positive SPF
authentication.

So, theoretically, if we look at it that way, there are a couple of
upsides, although obviously there is additional added complexity, and as
Doug surmised, the adaptation of mail filters will take a
significant amount of time before we see any semblance of ubiquitous
adoption.

I'm on the fence currently about the auth= method.

- Mark Alley

On Sun, Oct 29, 2023, 2:35 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Reporting allows certainty within the limits of the reporting mechanism.
> My inference is that many domains stop at p=none for an extended period or
> forever because the reporting mechanism does not provide that certainty.
>  For my part, I backed away from reject when I received fail-with-reject
> reports from Outlook.com.  These proved to be false results (messages were
> not blocked) but the fear remained.  Since then, domain members have
> started participating with mailing lists, and I have not determined how the
> list handles p=reject participation.  So I am back at none.
>
> More importantly, the SPF neutral gimmick can be applied immediately, with
> confidence that it will be handled as intended by essentially all
> evaluators.
>
> By contrast, the new tag cannot be effective until DMARCbis is published
> and filtering software updated.  This involves years.  Even then, domain
> owners will never have confidence that the new token support has been
> implemented by all recipient evaluators.
>
> Additionally, we have testimony that the neutral gimmick has been recently
> used on a large scale, to block SPf upgrade attacks, with good results.
>
> Seems like a slam dunk for SPF neutral.  I said the problem and it's
> solution needs to be laid out in our document because I am one of those who
> did not understand it as a possible strategy
>
> Doug
>
> On Sun, Oct 29, 2023, 2:03 PM Richard Clayton 
> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> In message > f...@mail.gmail.com>, Douglas Foster > m> writes
>>
>> >* auth=DKIMOnly requires that the domain owner have high confidence
>> >  that every message source is applying DKIM signatures.
>>
>> which of course the reporting mechanism allows them to acquire
>>
>> - --
>> richard   Richard Clayton
>>
>> Those who would give up essential Liberty, to purchase a little temporary
>> Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755
>>
>> -BEGIN PGP SIGNATURE-
>> Version: PGPsdk version 1.7.1
>>
>> iQA/AwUBZT6d+N2nQQHFxEViEQJCDQCgi6nTZzBMtD3IsCneeBhfi9yncr4An1Rw
>> XWnnTNQEzFoispkq3McuQGgw
>> =PlmH
>> -END PGP SIGNATURE-
>>
>> ___
>> 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] DMARCbis way forward: Do we need our session at IETF 118

[Douglas Foster]

Reporting allows certainty within the limits of the reporting mechanism.
My inference is that many domains stop at p=none for an extended period or
forever because the reporting mechanism does not provide that certainty.
 For my part, I backed away from reject when I received fail-with-reject
reports from Outlook.com.  These proved to be false results (messages were
not blocked) but the fear remained.  Since then, domain members have
started participating with mailing lists, and I have not determined how the
list handles p=reject participation.  So I am back at none.

More importantly, the SPF neutral gimmick can be applied immediately, with
confidence that it will be handled as intended by essentially all
evaluators.

By contrast, the new tag cannot be effective until DMARCbis is published
and filtering software updated.  This involves years.  Even then, domain
owners will never have confidence that the new token support has been
implemented by all recipient evaluators.

Additionally, we have testimony that the neutral gimmick has been recently
used on a large scale, to block SPf upgrade attacks, with good results.

Seems like a slam dunk for SPF neutral.  I said the problem and it's
solution needs to be laid out in our document because I am one of those who
did not understand it as a possible strategy

Doug

On Sun, Oct 29, 2023, 2:03 PM Richard Clayton 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> In message  f...@mail.gmail.com>, Douglas Foster  m> writes
>
> >* auth=DKIMOnly requires that the domain owner have high confidence
> >  that every message source is applying DKIM signatures.
>
> which of course the reporting mechanism allows them to acquire
>
> - --
> richard   Richard Clayton
>
> Those who would give up essential Liberty, to purchase a little temporary
> Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755
>
> -BEGIN PGP SIGNATURE-
> Version: PGPsdk version 1.7.1
>
> iQA/AwUBZT6d+N2nQQHFxEViEQJCDQCgi6nTZzBMtD3IsCneeBhfi9yncr4An1Rw
> XWnnTNQEzFoispkq3McuQGgw
> =PlmH
> -END PGP SIGNATURE-
>
> ___
> 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] DMARCbis way forward: Do we need our session at IETF 118

[Richard Clayton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In message , Douglas Foster  writes

>* auth=DKIMOnly requires that the domain owner have high confidence 
>  that every message source is applying DKIM signatures.

which of course the reporting mechanism allows them to acquire

- -- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.7.1

iQA/AwUBZT6d+N2nQQHFxEViEQJCDQCgi6nTZzBMtD3IsCneeBhfi9yncr4An1Rw
XWnnTNQEzFoispkq3McuQGgw
=PlmH
-END PGP SIGNATURE-

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Douglas Foster]

I have become persuaded to Scott's approach, as long as it is documented
clearly.

For DMARC-enabled evaluators:

   - auth=DKIMOnly requires that the domain owner have high confidence that
   every message source is applying DKIM signatures.
   - ?include=hostingservice only requires knowledge that one particular
   message source has implemented DKIM signatures.

Because certainty can be hard to achieve, the requirement for 100%
participation may be a significant obstacle.   ?include allows the rule to
be applied tactically where needed (on multi-tenant hosting services) and
bypassed elsewhere (when SPF upgrade is not a concern).

For SPF-only evaluators:
I have some experience with four different SPF-only products, and in each
case, when the SPF test is enabled, the disposition is "block on SPF FAIL,
allow on any other result".  Therefore I think the risk is low that a
change from PASS to NEUTRAL will actually cause legitimate messages to be
blocked.

In sum, no expected impact on SPF-only evaluators, and immediate SPF
Upgrade protection for evaluators that are compliant with both SPF and
DMARC specifications.

Doug Foster


On Sun, Oct 29, 2023 at 9:44 AM Richard Clayton 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> In message  il.com>, Wei Chuang  writes
>
> >I don't think the SPF '?' qualifier approach works because as Richard
> >Clayton said earlier of RFC7208 "Sender Policy Framework (SPF) for
> >Authorizing Use of Domains in Email, Version 1" section 8.2 which says:
> >
> >A "neutral" result MUST be treated exactly like the "none"  result;
> >the distinction exists only for informational purposes.
>
> Scott pointed out that I had not understood it correctly ... when you
> run a matching sending IP against a "?" mechanism then you get "neutral"
> which you are obliged to treat as "none". But you stop there.
>
> When you run a non-matching sending IP against that same "?" mechanism
> then you get a "fail" so you keep on going to look at all the other
> mechanisms (which also all fail) and eventually (in practice) reach
> "-all" or "~all" at the end of the record.
>
> hence you can still use SPF to filter out the non-starters, but you
> don't get any warm and fuzzy feeling from the pass...
>
> So the SPF publisher they can either publish "?" information or nothing
> at all -- and the _only_ reason for doing the former is to help with an
> initial filtering mechanism at sites that use SPF for that purpose.
>
> >If it happens to work, it's likely an implementation detail not
> >standardized across the ecosystem and may change.
>
> You're right that there's no way of knowing whether the people who are
> currently paying a lot of attention to SPF (and less so to DKIM) are
> going to make poorer decisions when what used to be an SPF pass now
> becomes a "none" result.
>
> Allowing DKIM-only to be specified in DMARC allows people to still
> publish SPF records that yield a pass (thus generating a (possibly
> mistaken) warm and fuzzy feeling in some quarters ...)
>
> >Moreover it will be
> >highly confusing to those outside of those with connection to the
> >knowledgeable few.  That broader community depends on the literal
> >interpretation of the RFC.
>
> That's what still confuses me about the objections to the proposal to
> explicitly allow people to say "DKIM only".
>
> Yes I get that it adds a little bit to the text of the document and
> requires a bit more code to parse the new parameter and hence you can
> object on the basis of "complexity" -- but it does seem simpler to
> understand the stricture "ignore SPF" than grok the necessity to alter
> SPF records to use a complex-to-understand mechanism which may degrade
> some deliverability.
>
> - --
> richard   Richard Clayton
>
> Those who would give up essential Liberty, to purchase a little temporary
> Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755
>
> -BEGIN PGP SIGNATURE-
> Version: PGPsdk version 1.7.1
>
> iQA/AwUBZT5hO92nQQHFxEViEQIM0gCfU3ZV3bEfi9kAfEFThr+30GJWqFsAoI2z
> xh0KGaaD5mELlRimHgVMwRDu
> =HmrF
> -END PGP SIGNATURE-
>
> ___
> 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] DMARCbis way forward: Do we need our session at IETF 118

[Richard Clayton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In message , Wei Chuang  writes

>I don't think the SPF '?' qualifier approach works because as Richard
>Clayton said earlier of RFC7208 "Sender Policy Framework (SPF) for
>Authorizing Use of Domains in Email, Version 1" section 8.2 which says:
>
>A "neutral" result MUST be treated exactly like the "none"  result;
>the distinction exists only for informational purposes.

Scott pointed out that I had not understood it correctly ... when you
run a matching sending IP against a "?" mechanism then you get "neutral"
which you are obliged to treat as "none". But you stop there.

When you run a non-matching sending IP against that same "?" mechanism
then you get a "fail" so you keep on going to look at all the other
mechanisms (which also all fail) and eventually (in practice) reach
"-all" or "~all" at the end of the record.

hence you can still use SPF to filter out the non-starters, but you
don't get any warm and fuzzy feeling from the pass...

So the SPF publisher they can either publish "?" information or nothing
at all -- and the _only_ reason for doing the former is to help with an
initial filtering mechanism at sites that use SPF for that purpose.

>If it happens to work, it's likely an implementation detail not
>standardized across the ecosystem and may change.  

You're right that there's no way of knowing whether the people who are
currently paying a lot of attention to SPF (and less so to DKIM) are
going to make poorer decisions when what used to be an SPF pass now
becomes a "none" result.

Allowing DKIM-only to be specified in DMARC allows people to still
publish SPF records that yield a pass (thus generating a (possibly
mistaken) warm and fuzzy feeling in some quarters ...) 

>Moreover it will be
>highly confusing to those outside of those with connection to the
>knowledgeable few.  That broader community depends on the literal
>interpretation of the RFC.

That's what still confuses me about the objections to the proposal to
explicitly allow people to say "DKIM only".

Yes I get that it adds a little bit to the text of the document and
requires a bit more code to parse the new parameter and hence you can
object on the basis of "complexity" -- but it does seem simpler to
understand the stricture "ignore SPF" than grok the necessity to alter
SPF records to use a complex-to-understand mechanism which may degrade
some deliverability.

- -- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.7.1

iQA/AwUBZT5hO92nQQHFxEViEQIM0gCfU3ZV3bEfi9kAfEFThr+30GJWqFsAoI2z
xh0KGaaD5mELlRimHgVMwRDu
=HmrF
-END PGP SIGNATURE-

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Alessandro Vesely]

On Sat 28/Oct/2023 16:51:27 +0200 Scott Kitterman wrote:

On October 28, 2023 12:01:05 PM UTC, Alessandro Vesely  wrote:


You're the only one strongly opposing the idea, AFAICS, and I still don't know 
why.


As to why, I don't think there's a valid use case and the proponents for this 
haven't really thought it through.  As an example, someone (I don't recall who) 
cited the issue of domain owners that publish SPF, but can't be bothered to set 
up DKIM.  The implication is that this minimum effort domain owner will read 
DMARCbis when it comes out and decide to update their records as a result with 
the new tag.  I don't think that's very realistic.

So who would use this tag then?

It would have to be a domain owner which publishes an SPF record that enables 
spoofing their domain, understands SPF and DMARC well enough to know that is a 
concern for DMARC and yet simultaneously doesn't know how to fix their SPF 
record and does know about this new tag.

I don't think that person exists.  At best this new tag is some kind of 
security theater.



Perhaps your hypothetical domain owner knows how to fix SPF records, but 
/prefers/ to use auth=dkim.  Actually, she has to fix SPF records anyway, for 
DMARC parsers which don't recognize the new tag.


Being a security theater would match the other use of auth=, to purify DMARC by 
eliminating years of mumbo-jumbo SPF advice.  In case that becomes a widespread 
trend, DMARCter could drop SPF for good.




I think this is the only thing we're doing in DMARCbis that will actively 
worsen DMARC.



No, that is t=.  auth= would be backward compatible.


Best
Ale
--


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Mark Alley]

The intended purpose of using it in the referenced scenario is to avoid the
negative connotation of ~ or - on their shared infrastructure mechanism(s)
in SPF evaluation, while also producing a non-pass for SPF to DMARC.

Many receivers use the failure SPF results as additional signals to
spam/junk filtering; if a sender used the latter two (~ or -) instead of
neutral (?), it would only cause more issues.

But as you stated, I agree the handling of the neutral qualifier is most
likely non-standardized across the internet.


- Mark Alley


On Sun, Oct 29, 2023, 1:39 AM Wei Chuang 
wrote:

> I don't think the SPF '?' qualifier approach works because as Richard
> Clayton said earlier of RFC7208 "Sender Policy Framework (SPF) for
> Authorizing Use of Domains in Email, Version 1" section 8.2 which says:
>
> A "neutral" result MUST be treated exactly like the "none"  result;
> the distinction exists only for informational purposes.
>
> If it happens to work, it's likely an implementation detail not
> standardized across the ecosystem and may change.  Moreover it will be
> highly confusing to those outside of those with connection to the
> knowledgeable few.  That broader community depends on the literal
> interpretation of the RFC.
> -Wei
>
> On Sat, Oct 28, 2023 at 3:58 PM Mark Alley  40tekmarc@dmarc.ietf.org> wrote:
>
>> For the shared provider SPF upgrade example, I think Scott's previously
>> mentioned method of using SPF '?' qualifier on the relevant shared
>> mechanism mitigates the upgrade problem, and ensures only DKIM can provide
>> passing authentication.
>>
>> Thinking back earlier this year to the well-publicized SPF upgrade
>> vulnerability of a certain vendor, many affected senders mitigated it until
>> fixed by the vendor by utilizing the aforementioned neutral ? qualifier
>> method to great effect.
>>
>> Do we really need this when existing protocol methods of mitigating SPF
>> upgrades already exist?
>>
>> This is basically like painting a potato red, and calling it a tomato. It
>> still tastes like a potato.
>>
>> -Mark Alley
>>
>> On Sat, Oct 28, 2023, 3:04 PM Emanuel Schorsch > 40google@dmarc.ietf.org> wrote:
>>
>>> As to why, I don't think there's a valid use case and the proponents for
 this haven't really thought it through.  As an example, someone (I don't
 recall who) cited the issue of domain owners that publish SPF, but can't be
 bothered to set up DKIM.  The implication is that this minimum effort
 domain owner will read DMARCbis when it comes out and decide to update
 their records as a result with the new tag.  I don't think that's very
 realistic.

 So who would use this tag then?

 It would have to be a domain owner which publishes an SPF record that
 enables spoofing their domain, understands SPF and DMARC well enough to
 know that is a concern for DMARC and yet simultaneously doesn't know how to
 fix their SPF record and does know about this new tag.

 I don't think that person exists.  At best this new tag is some kind of
 security theater.

>>>
>>> Thanks for that clarification! I think I can clear up what the specific
>>> use case is. It's to deal with SPF Upgrade. Assume we have a domain, `
>>> business.com`, that has properly set up SPF and DKIM and uses a shared
>>> provider and so includes the relevant provider IPs in their SPF record.
>>> They have a DMARC p=reject policy. But, unfortunately, the shared provider
>>> they use is vulnerable to SPF upgrade and so there have been successful
>>> upgrades allowing a spammer / phisher to achieve a `business.com` SPF
>>> pass. Notably, this does not allow the spammer to achieve a `
>>> business.com` DKIM pass. Today, this will be a DMARC pass (because of
>>> the SPF), and it is not always so easy for downstream receivers to know
>>> there has been an upgrade.
>>>
>>> Take the above example, and imagine we've added an `auth=dkim` tag
>>> option. `business.com` then adds it to their DMARC record to protect
>>> their domain. Now, when a receiver gets the upgraded message they see it is
>>> a DMARC fail and can reject the message. This protects the `business.com`
>>> domain from impersonation in a way that is not possible today without `
>>> business.com` either removing SPF or leaving their shared provider (the
>>> only ways to "fix their SPF record"), both a much larger change. Does that
>>> make more sense as a legitimate use case?
>>> ___
>>> 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

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Alessandro Vesely]

On Sat 28/Oct/2023 17:28:50 +0200 Scott Kitterman wrote:



We need to add a subsection in Security Consideration, discussing an
example of an include mechanism with a neutral qualifier and its effect on
DMARC outcome; that is, how that avoids spurious authentications.


I disagree.  It's already addressed in RFC 7208 and we have:

11.1.  Authentication Methods

   Security considerations from the authentication methods used by DMARC
   are incorporated here by reference.

It's already covered.


I thought some more about this and maybe we should put something in about
this.



Thank you for your intellectual honesty.



 Maybe something like:

Domains which publish SPF records that include mechanisms which relate to mail
services which do not protect against cross-user forgery (RFC 7208, Section
11.4) are advised to do so only with the '?' qualifier to mitigate the risk
that such spoofed messages will receive a DMARC pass result.



That's a good start.  I think we should add an example showing, say:

"v=spf1 ?include:spf.protection.extra-large-domain.example -all"

It seems to me that people have the false persuasion that qualifiers can only 
be used in the all mechanism.



Best
Ale
--



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Alessandro Vesely]

On Sun 29/Oct/2023 07:39:09 +0100 Wei Chuang wrote:
I don't think the SPF '?' qualifier approach works because as Richard 
Clayton said earlier of RFC7208 "Sender Policy Framework (SPF) for 
Authorizing Use of Domains in Email, Version 1" section 8.2 which says:


 A "neutral" result MUST be treated exactly like the "none"  result;
 the distinction exists only for informational purposes.

If it happens to work, it's likely an implementation detail not 
standardized across the ecosystem and may change.  Moreover it will be 
highly confusing to those outside of those with connection to the 
knowledgeable few.  That broader community depends on the literal 
interpretation of the RFC.



Obviously, using ?include is only meaningful for SPF records ending in -all. 
Some receivers don't reject even when they find -all.  I don't think there are 
receivers that reject when they see ?all or ~all.  So the question is:


Is there a real difference between spf=neutral and spf=pass,
apart from its effect on DMARC?

IOW, why do domains that apply DKIM signatures undergo the effort to set up a 
complicated SPF record ending in ~all, when they could just have set "v=spf1 
~all" and obtain a DMARC pass via DKIM?


Like kitterman.com, tana.it also makes use of the neutral qualifier, but we are 
small senders.  State.gov uses -all but doesn't use the neutral qualifier.  I 
think they want to use the SPF ability to have spoofs rejected, which was SPF 
original goal.  Using the neutral qualifier would work for them too, no?



Best
Ale
--




___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Wei Chuang]

I don't think the SPF '?' qualifier approach works because as Richard
Clayton said earlier of RFC7208 "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1" section 8.2 which says:

A "neutral" result MUST be treated exactly like the "none"  result;
the distinction exists only for informational purposes.

If it happens to work, it's likely an implementation detail not
standardized across the ecosystem and may change.  Moreover it will be
highly confusing to those outside of those with connection to the
knowledgeable few.  That broader community depends on the literal
interpretation of the RFC.
-Wei

On Sat, Oct 28, 2023 at 3:58 PM Mark Alley  wrote:

> For the shared provider SPF upgrade example, I think Scott's previously
> mentioned method of using SPF '?' qualifier on the relevant shared
> mechanism mitigates the upgrade problem, and ensures only DKIM can provide
> passing authentication.
>
> Thinking back earlier this year to the well-publicized SPF upgrade
> vulnerability of a certain vendor, many affected senders mitigated it until
> fixed by the vendor by utilizing the aforementioned neutral ? qualifier
> method to great effect.
>
> Do we really need this when existing protocol methods of mitigating SPF
> upgrades already exist?
>
> This is basically like painting a potato red, and calling it a tomato. It
> still tastes like a potato.
>
> -Mark Alley
>
> On Sat, Oct 28, 2023, 3:04 PM Emanuel Schorsch  40google@dmarc.ietf.org> wrote:
>
>> As to why, I don't think there's a valid use case and the proponents for
>>> this haven't really thought it through.  As an example, someone (I don't
>>> recall who) cited the issue of domain owners that publish SPF, but can't be
>>> bothered to set up DKIM.  The implication is that this minimum effort
>>> domain owner will read DMARCbis when it comes out and decide to update
>>> their records as a result with the new tag.  I don't think that's very
>>> realistic.
>>>
>>> So who would use this tag then?
>>>
>>> It would have to be a domain owner which publishes an SPF record that
>>> enables spoofing their domain, understands SPF and DMARC well enough to
>>> know that is a concern for DMARC and yet simultaneously doesn't know how to
>>> fix their SPF record and does know about this new tag.
>>>
>>> I don't think that person exists.  At best this new tag is some kind of
>>> security theater.
>>>
>>
>> Thanks for that clarification! I think I can clear up what the specific
>> use case is. It's to deal with SPF Upgrade. Assume we have a domain, `
>> business.com`, that has properly set up SPF and DKIM and uses a shared
>> provider and so includes the relevant provider IPs in their SPF record.
>> They have a DMARC p=reject policy. But, unfortunately, the shared provider
>> they use is vulnerable to SPF upgrade and so there have been successful
>> upgrades allowing a spammer / phisher to achieve a `business.com` SPF
>> pass. Notably, this does not allow the spammer to achieve a `business.com`
>> DKIM pass. Today, this will be a DMARC pass (because of the SPF), and it is
>> not always so easy for downstream receivers to know there has been an
>> upgrade.
>>
>> Take the above example, and imagine we've added an `auth=dkim` tag
>> option. `business.com` then adds it to their DMARC record to protect
>> their domain. Now, when a receiver gets the upgraded message they see it is
>> a DMARC fail and can reject the message. This protects the `business.com`
>> domain from impersonation in a way that is not possible today without `
>> business.com` either removing SPF or leaving their shared provider (the
>> only ways to "fix their SPF record"), both a much larger change. Does that
>> make more sense as a legitimate use case?
>> ___
>> 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] DMARCbis way forward: Do we need our session at IETF 118

[Scott Kitterman]

On Saturday, October 28, 2023 4:03:30 PM EDT Emanuel Schorsch wrote:
> > As to why, I don't think there's a valid use case and the proponents for
> > this haven't really thought it through.  As an example, someone (I don't
> > recall who) cited the issue of domain owners that publish SPF, but can't
> > be
> > bothered to set up DKIM.  The implication is that this minimum effort
> > domain owner will read DMARCbis when it comes out and decide to update
> > their records as a result with the new tag.  I don't think that's very
> > realistic.
> > 
> > So who would use this tag then?
> > 
> > It would have to be a domain owner which publishes an SPF record that
> > enables spoofing their domain, understands SPF and DMARC well enough to
> > know that is a concern for DMARC and yet simultaneously doesn't know how
> > to
> > fix their SPF record and does know about this new tag.
> > 
> > I don't think that person exists.  At best this new tag is some kind of
> > security theater.
> 
> Thanks for that clarification! I think I can clear up what the specific use
> case is. It's to deal with SPF Upgrade. Assume we have a domain, `
> business.com`, that has properly set up SPF and DKIM and uses a shared
> provider and so includes the relevant provider IPs in their SPF record.
> They have a DMARC p=reject policy. But, unfortunately, the shared provider
> they use is vulnerable to SPF upgrade and so there have been successful
> upgrades allowing a spammer / phisher to achieve a `business.com` SPF pass.
> Notably, this does not allow the spammer to achieve a `business.com` DKIM
> pass. Today, this will be a DMARC pass (because of the SPF), and it is not
> always so easy for downstream receivers to know there has been an upgrade.
> 
> Take the above example, and imagine we've added an `auth=dkim` tag option. `
> business.com` then adds it to their DMARC record to protect their domain.
> Now, when a receiver gets the upgraded message they see it is a DMARC fail
> and can reject the message. This protects the `business.com` domain from
> impersonation in a way that is not possible today without `business.com`
> either removing SPF or leaving their shared provider (the only ways to "fix
> their SPF record"), both a much larger change. Does that make more sense as
> a legitimate use case?

For that to be useful, it needs a domain owner which understand SPF and their 
providers well enough to know they need to include this new tag, but not well 
enough to know they can used a neutral qualifier in their SPF records (as Mark 
Alley just mentioned, there are alternatives other than removing their SPF or 
leaving the provider).  The is precisely the domain owner that I don't believe 
exists (and I think Mark's input supports that there are other ways to solve 
this).

Ultimately, if I domain's reputation suffers because it uses shared 
infrastructure that isn't sufficiently careful to avoid cross-user forgery, I 
think the system is working as designed.  They should either get the provider 
to clean up their act or leave if they want a high reputation.  That's just 
market forces as work, which I think is the best way to solve this.

It may be that what we need to do is add some language about not inferring too 
much from DMARC pass.  Since both DKIM and SPF have upgrade attack risks, I 
think ultimately people are over-reliant on what a DMARC pass means.

Scott K



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Mark Alley]

For the shared provider SPF upgrade example, I think Scott's previously
mentioned method of using SPF '?' qualifier on the relevant shared
mechanism mitigates the upgrade problem, and ensures only DKIM can provide
passing authentication.

Thinking back earlier this year to the well-publicized SPF upgrade
vulnerability of a certain vendor, many affected senders mitigated it until
fixed by the vendor by utilizing the aforementioned neutral ? qualifier
method to great effect.

Do we really need this when existing protocol methods of mitigating SPF
upgrades already exist?

This is basically like painting a potato red, and calling it a tomato. It
still tastes like a potato.

-Mark Alley

On Sat, Oct 28, 2023, 3:04 PM Emanuel Schorsch  wrote:

> As to why, I don't think there's a valid use case and the proponents for
>> this haven't really thought it through.  As an example, someone (I don't
>> recall who) cited the issue of domain owners that publish SPF, but can't be
>> bothered to set up DKIM.  The implication is that this minimum effort
>> domain owner will read DMARCbis when it comes out and decide to update
>> their records as a result with the new tag.  I don't think that's very
>> realistic.
>>
>> So who would use this tag then?
>>
>> It would have to be a domain owner which publishes an SPF record that
>> enables spoofing their domain, understands SPF and DMARC well enough to
>> know that is a concern for DMARC and yet simultaneously doesn't know how to
>> fix their SPF record and does know about this new tag.
>>
>> I don't think that person exists.  At best this new tag is some kind of
>> security theater.
>>
>
> Thanks for that clarification! I think I can clear up what the specific
> use case is. It's to deal with SPF Upgrade. Assume we have a domain, `
> business.com`, that has properly set up SPF and DKIM and uses a shared
> provider and so includes the relevant provider IPs in their SPF record.
> They have a DMARC p=reject policy. But, unfortunately, the shared provider
> they use is vulnerable to SPF upgrade and so there have been successful
> upgrades allowing a spammer / phisher to achieve a `business.com` SPF
> pass. Notably, this does not allow the spammer to achieve a `business.com`
> DKIM pass. Today, this will be a DMARC pass (because of the SPF), and it is
> not always so easy for downstream receivers to know there has been an
> upgrade.
>
> Take the above example, and imagine we've added an `auth=dkim` tag option.
> `business.com` then adds it to their DMARC record to protect their
> domain. Now, when a receiver gets the upgraded message they see it is a
> DMARC fail and can reject the message. This protects the `business.com`
> domain from impersonation in a way that is not possible today without `
> business.com` either removing SPF or leaving their shared provider (the
> only ways to "fix their SPF record"), both a much larger change. Does that
> make more sense as a legitimate use case?
> ___
> 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] DMARCbis way forward: Do we need our session at IETF 118

[Emanuel Schorsch]

>
> As to why, I don't think there's a valid use case and the proponents for
> this haven't really thought it through.  As an example, someone (I don't
> recall who) cited the issue of domain owners that publish SPF, but can't be
> bothered to set up DKIM.  The implication is that this minimum effort
> domain owner will read DMARCbis when it comes out and decide to update
> their records as a result with the new tag.  I don't think that's very
> realistic.
>
> So who would use this tag then?
>
> It would have to be a domain owner which publishes an SPF record that
> enables spoofing their domain, understands SPF and DMARC well enough to
> know that is a concern for DMARC and yet simultaneously doesn't know how to
> fix their SPF record and does know about this new tag.
>
> I don't think that person exists.  At best this new tag is some kind of
> security theater.
>

Thanks for that clarification! I think I can clear up what the specific use
case is. It's to deal with SPF Upgrade. Assume we have a domain, `
business.com`, that has properly set up SPF and DKIM and uses a shared
provider and so includes the relevant provider IPs in their SPF record.
They have a DMARC p=reject policy. But, unfortunately, the shared provider
they use is vulnerable to SPF upgrade and so there have been successful
upgrades allowing a spammer / phisher to achieve a `business.com` SPF pass.
Notably, this does not allow the spammer to achieve a `business.com` DKIM
pass. Today, this will be a DMARC pass (because of the SPF), and it is not
always so easy for downstream receivers to know there has been an upgrade.

Take the above example, and imagine we've added an `auth=dkim` tag option. `
business.com` then adds it to their DMARC record to protect their domain.
Now, when a receiver gets the upgraded message they see it is a DMARC fail
and can reject the message. This protects the `business.com` domain from
impersonation in a way that is not possible today without `business.com`
either removing SPF or leaving their shared provider (the only ways to "fix
their SPF record"), both a much larger change. Does that make more sense as
a legitimate use case?
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Hector Santos]

Fwiiw, Lurker opinion:

I ideally vote to make DMARCBis Experimental Status and begin to explore the 
“required” integration between envelope (5321 only) protocols and payload 
(5322) protocols. Specifically, work on a “proper” DKIM+SPF Policy Modeling 
with 3rd party signature support. 

But realistically, we should finish DMARCBis as is, as Levine desires.  
However, imto, keeping it a Standard Track will increase the ignorance.  I 
don’t see any new gains for current my package implementation.  At best, the 
industry is acknowledging a big integration problem. Domains who can’ get past 
sending mail the large Mall Hosting domains and managed domains DMARC 
processing are learning to relax their policies. 

PS:  I don’t plan any appeal 

—
HLS


> On Oct 28, 2023, at 12:49 PM, Murray S. Kucherawy  wrote:
> 
> On Sat, Oct 28, 2023 at 8:28 AM Richard Clayton  > wrote:
>> Paying attention to the (sometimes inferred) age of a signature is also
>> important for reducing the opportunity for replay, viz: it would be a
>> Good Thing for senders to set appropriately short expire times.
> 
> Why does it have to be inferred sometimes?  Have you found "t=" values to be 
> occasionally inaccurate?
> 
> The DKIM standard advises against using "x=" to combat replay attacks.  We 
> could always update that advice, but we might also want to review why it was 
> put there in the first place.  I remember the reason being a good one.
> 
> I think there's also been discussion around the reliability of "x=" across 
> implementations.  Since it's not mandatory to support, it doesn't seem to be 
> very common to produce without the expectation of consumers.
> 
> -MSK, participating
> ___
> 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] DMARCbis way forward: Do we need our session at IETF 118

[Murray S. Kucherawy]

On Sat, Oct 28, 2023 at 8:28 AM Richard Clayton 
wrote:

> Paying attention to the (sometimes inferred) age of a signature is also
> important for reducing the opportunity for replay, viz: it would be a
> Good Thing for senders to set appropriately short expire times.
>

Why does it have to be inferred sometimes?  Have you found "t=" values to
be occasionally inaccurate?

The DKIM standard advises against using "x=" to combat replay attacks.  We
could always update that advice, but we might also want to review why it
was put there in the first place.  I remember the reason being a good one.

I think there's also been discussion around the reliability of "x=" across
implementations.  Since it's not mandatory to support, it doesn't seem to
be very common to produce without the expectation of consumers.

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Scott Kitterman]

On Saturday, October 28, 2023 11:26:40 AM EDT Richard Clayton wrote:
> In message <3316620.Pp0j0xxFaF@localhost>, Scott Kitterman
>  writes
> 
> >What's your plan for when easily getting a DMARC pass due to bad SPF
> >records doesn't work anymore, so the bad guys focus more on DKIM replay?
> 
> At $DAYJOB$, DKIM replay is simply not an issue any more ... caching
> DKIM values and blocking more than N emails with the same value (whilst
> of course exempting mailing lists) has proved extremely effective for
> several years now.
> 
> Paying attention to the (sometimes inferred) age of a signature is also
> important for reducing the opportunity for replay, viz: it would be a
> Good Thing for senders to set appropriately short expire times.

I guess that works as long as N - 1 spoofed DMARC pass results is OK.  I think 
not everyone has been so fortunate.  I expect it will get more focus if cross-
user forgery for SPF stops working as well.

Scott K




___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Scott Kitterman]

On Saturday, October 28, 2023 10:51:27 AM EDT Scott Kitterman wrote:
> >Even if we don't add the feature, we should address the vulnerability. 
Currently there is only a bullet in Section 4.8, Organizational Domain 
Discovery, saying:
> > * The domain found in the RFC5321.MailFrom header if there is an SPF
> > pass result for the message being evaluated.
> >
> >We need to add a subsection in Security Consideration, discussing an
> >example of an include mechanism with a neutral qualifier and its effect on
> >DMARC outcome; that is, how that avoids spurious authentications.
> >
> >The other snippet where SPF qualifiers are discussed is Section 8.1, Issues
> >Specific to SPF.  We could add a reference to the added subsection there.
> I disagree.  It's already addressed in RFC 7208 and we have:
> 
> 11.1.  Authentication Methods
> 
>Security considerations from the authentication methods used by DMARC
>are incorporated here by reference.
> 
> It's already covered.

I thought some more about this and maybe we should put something in about 
this.  Maybe something like:

Domains which publish SPF records that include mechanisms which relate to mail 
services which do not protect against cross-user forgery (RFC 7208, Section 
11.4) are advised to do so only with the '?' qualifier to mitigate the risk 
that such spoofed messages will receive a DMARC pass result.

Scott K


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Richard Clayton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In message <3316620.Pp0j0xxFaF@localhost>, Scott Kitterman
 writes

>What's your plan for when easily getting a DMARC pass due to bad SPF records 
>doesn't work anymore, so the bad guys focus more on DKIM replay?

At $DAYJOB$, DKIM replay is simply not an issue any more ... caching
DKIM values and blocking more than N emails with the same value (whilst
of course exempting mailing lists) has proved extremely effective for
several years now.

Paying attention to the (sometimes inferred) age of a signature is also
important for reducing the opportunity for replay, viz: it would be a
Good Thing for senders to set appropriately short expire times.

- -- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.7.1

iQA/AwUBZT0oMN2nQQHFxEViEQLj2wCg9sCc40wN2UuXY4/Ms7TuMtt/QlAAn1/V
kAUjrpkVAoDkoMlPbVsn1I4X
=tMcf
-END PGP SIGNATURE-

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Scott Kitterman]

On Saturday, October 28, 2023 10:49:46 AM EDT Richard Clayton wrote:
> In message <6bb2871c-da84-42ad-bae1-7b4828b0f...@tana.it>, Alessandro
> Vesely  writes
> 
> >On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote:
> >> On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely  
wrote:
> >>>If we add the feature, we should in any case exemplify how to fix SPF,
> >>>saying>
> >that doing so is safer, at least until all DMARC software has acquired the
> >new feature.  As the addition would be understood as a response to the
> >known vulnerability, it will likely be spread.
> >
> >> What do we know now that we didn't know the last time we decided not to
> >> go
> >
> >DKIM only?  I'd argue there's nothing and endless relitigation of issues
> >like this is making it impossible to actually accomplish what we're
> >chartered to accomplish.
> >
> >You're the only one strongly opposing the idea, AFAICS, and I still don't
> >know why.
> 
> The only reason that I think that SPF results are of any value at all
> (and hence we should go with a "DKIM pass only" marker for those who
> need it, rather than just wiping SPF from the document) is because some
> people have argued that a SPF only approach is of value to them -- they
> can do a sanity check on the sending IP, and they then use other methods
> to decide whether they like the email. Their server their choice...
> 
> ... Scott has been arguing (AIUI) that people who want a DKIM only
> situation should add the "?" qualifier to relevant SPF mechanisms. This
> will produce a "neutral" result and hence there will not be a SPF pass
> for DMARC to consider.
> 
> This is all very well, but I have been reading RFC7208 "Sender Policy
> Framework (SPF) for Authorizing Use of Domains in Email, Version 1"
> (which we should note is authored by S Kitterman) and in particular
> looking at #8.2 which says:
> 
> A "neutral" result MUST be treated exactly like the "none"  result;
> the distinction exists only for informational purposes.
> 
> that is (and Scott can correct me if I misunderstand), that people using
> SPF in an RFC compliant manner (which the libraries they use will
> undoubtedly do) are effectively obliged to ignore any mechanism with a
> "?" qualifier.  BTW the same text appears in RFC4408 #2.5.2. so this has
> always been the case.
> 
> That is -- using "?" means that the SPF information will not only be
> disregarded for DMARC purposes but also for SPF purposes as well.
> 
> In my view that makes promoting the use of "?" a non-starter. So if we
> want to allow the people who value SPF to continue to have records they
> can use whilst addressing the reality that such records are often,
> necessarily, far too wide to provide real authentication, we must have a
> way in DMARC of saying "only consider DKIM".

It's not "ignore the mechanism", it's "stop processing and the result in 
Neutral".

The idea behind this is that if you get a match from a mechanism with the '?' 
qualifier processing stops, so you never get to the end of the record.  As a 
result messages from that particular source don't reach the final 'all' 
mechanism.  It's not some kind of global thing, it's just for that source.  
This isn't a novel concept.  I've used it in the SPF record for kitterman.com 
for as long as I can remember for two relays I might, in theory, use, but I 
have no idea how they handle cross-user forgery risks.

What's your plan for when easily getting a DMARC pass due to bad SPF records 
doesn't work anymore, so the bad guys focus more on DKIM replay?  DMARC 
without DKIM as a solution?

Scott K


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Scott Kitterman]

On October 28, 2023 12:01:05 PM UTC, Alessandro Vesely  wrote:
>On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote:
>> On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely  wrote:
>>> On Fri 27/Oct/2023 12:34:11 +0200 John Levine wrote:
 
 If there isn't a consensus to do a DKIM-only feature, which seems to be 
 the case, I agree, wrap up the few minor editorial issues and we're done.
>>> 
>>> If we add the feature, we should in any case exemplify how to fix SPF, 
>>> saying that doing so is safer, at least until all DMARC software has 
>>> acquired the new feature.  As the addition would be understood as a 
>>> response to the known vulnerability, it will likely be spread.
>>> 
>>> As many of us consider it cleaner to have DMARC based on DKIM only, having 
>>> that possibility as an option is a first step in that direction anyway.  
>>> The thesis that DKIM is enough has been opposed but the only cases where 
>>> SPF saves the day seem to be software bugs.  The DKIM-only feature would 
>>> allow to probe that thesis, which fixing SPF records would not.
>> 
>> What do we know now that we didn't know the last time we decided not to go 
>> DKIM only?  I'd argue there's nothing and endless relitigation of issues 
>> like this is making it impossible to actually accomplish what we're 
>> chartered to accomplish.
>
>
>You're the only one strongly opposing the idea, AFAICS, and I still don't know 
>why.
>
Okay.  It sounded to me like you were pushing to reopen the debate about 
dropping SPF.

>> Let's either focus and finish or give up and close the group.
>
>
>Even if we don't add the feature, we should address the vulnerability. 
>Currently there is only a bullet in Section 4.8, Organizational Domain 
>Discovery, saying:
>
>* The domain found in the RFC5321.MailFrom header if there is an SPF
>  pass result for the message being evaluated.
>
>We need to add a subsection in Security Consideration, discussing an example 
>of an include mechanism with a neutral qualifier and its effect on DMARC 
>outcome; that is, how that avoids spurious authentications.
>
>The other snippet where SPF qualifiers are discussed is Section 8.1, Issues 
>Specific to SPF.  We could add a reference to the added subsection there.
>
I disagree.  It's already addressed in RFC 7208 and we have:

11.1.  Authentication Methods

   Security considerations from the authentication methods used by DMARC
   are incorporated here by reference.

It's already covered.

As to why, I don't think there's a valid use case and the proponents for this 
haven't really thought it through.  As an example, someone (I don't recall who) 
cited the issue of domain owners that publish SPF, but can't be bothered to set 
up DKIM.  The implication is that this minimum effort domain owner will read 
DMARCbis when it comes out and decide to update their records as a result with 
the new tag.  I don't think that's very realistic.

So who would use this tag then?

It would have to be a domain owner which publishes an SPF record that enables 
spoofing their domain, understands SPF and DMARC well enough to know that is a 
concern for DMARC and yet simultaneously doesn't know how to fix their SPF 
record and does know about this new tag.

I don't think that person exists.  At best this new tag is some kind of 
security theater.

So far, I don't think anyone has really said where this analysis is wrong.  
IETF consensus isn't about numbers.  It's about addressing issues raised by 
those in the rough and moving towards something we can all live with.

I think this is the only thing we're doing in DMARCbis that will actively 
worsen DMARC.  I'd like to either not include it or understand where I'm wrong.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Richard Clayton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In message <6bb2871c-da84-42ad-bae1-7b4828b0f...@tana.it>, Alessandro
Vesely  writes

>On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote:
>> On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely  wrote:

>>>If we add the feature, we should in any case exemplify how to fix SPF, 
>>>saying 
>that doing so is safer, at least until all DMARC software has acquired the new 
>feature.  As the addition would be understood as a response to the known 
>vulnerability, it will likely be spread.
>>>
>> What do we know now that we didn't know the last time we decided not to go 
>DKIM only?  I'd argue there's nothing and endless relitigation of issues like 
>this is making it impossible to actually accomplish what we're chartered to 
>accomplish.
>
>You're the only one strongly opposing the idea, AFAICS, and I still don't know 
>why.

The only reason that I think that SPF results are of any value at all
(and hence we should go with a "DKIM pass only" marker for those who
need it, rather than just wiping SPF from the document) is because some
people have argued that a SPF only approach is of value to them -- they
can do a sanity check on the sending IP, and they then use other methods
to decide whether they like the email. Their server their choice...

... Scott has been arguing (AIUI) that people who want a DKIM only
situation should add the "?" qualifier to relevant SPF mechanisms. This
will produce a "neutral" result and hence there will not be a SPF pass
for DMARC to consider.

This is all very well, but I have been reading RFC7208 "Sender Policy
Framework (SPF) for Authorizing Use of Domains in Email, Version 1"
(which we should note is authored by S Kitterman) and in particular
looking at #8.2 which says:

A "neutral" result MUST be treated exactly like the "none"  result;
the distinction exists only for informational purposes.  

that is (and Scott can correct me if I misunderstand), that people using
SPF in an RFC compliant manner (which the libraries they use will
undoubtedly do) are effectively obliged to ignore any mechanism with a
"?" qualifier.  BTW the same text appears in RFC4408 #2.5.2. so this has
always been the case.
 
That is -- using "?" means that the SPF information will not only be
disregarded for DMARC purposes but also for SPF purposes as well.

In my view that makes promoting the use of "?" a non-starter. So if we
want to allow the people who value SPF to continue to have records they
can use whilst addressing the reality that such records are often,
necessarily, far too wide to provide real authentication, we must have a
way in DMARC of saying "only consider DKIM".

- -- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.7.1

iQA/AwUBZT0fit2nQQHFxEViEQJiVgCg/QCfb5OmzSnGjXMiiTM7sPiepQcAniMF
q/BTNqNrSy8NfpE0xUvnktYF
=AHm6
-END PGP SIGNATURE-

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Alessandro Vesely]

On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote:

On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely  wrote:

On Fri 27/Oct/2023 12:34:11 +0200 John Levine wrote:


If there isn't a consensus to do a DKIM-only feature, which seems to be the 
case, I agree, wrap up the few minor editorial issues and we're done.


If we add the feature, we should in any case exemplify how to fix SPF, saying 
that doing so is safer, at least until all DMARC software has acquired the new 
feature.  As the addition would be understood as a response to the known 
vulnerability, it will likely be spread.

As many of us consider it cleaner to have DMARC based on DKIM only, having that 
possibility as an option is a first step in that direction anyway.  The thesis 
that DKIM is enough has been opposed but the only cases where SPF saves the day 
seem to be software bugs.  The DKIM-only feature would allow to probe that 
thesis, which fixing SPF records would not.


What do we know now that we didn't know the last time we decided not to go DKIM 
only?  I'd argue there's nothing and endless relitigation of issues like this 
is making it impossible to actually accomplish what we're chartered to 
accomplish.



You're the only one strongly opposing the idea, AFAICS, and I still don't know 
why.



Let's either focus and finish or give up and close the group.



Even if we don't add the feature, we should address the vulnerability. 
Currently there is only a bullet in Section 4.8, Organizational Domain 
Discovery, saying:


* The domain found in the RFC5321.MailFrom header if there is an SPF
  pass result for the message being evaluated.

We need to add a subsection in Security Consideration, discussing an example of 
an include mechanism with a neutral qualifier and its effect on DMARC outcome; 
that is, how that avoids spurious authentications.


The other snippet where SPF qualifiers are discussed is Section 8.1, Issues 
Specific to SPF.  We could add a reference to the added subsection there.



Best
Ale
--





___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Scott Kitterman]

On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely  wrote:
>On Fri 27/Oct/2023 12:34:11 +0200 John Levine wrote:
>> It appears that Scott Kitterman   said:
 That is unfortunately true, but if we could decouple the DMARC from SPF, 
 then at least we could fix the situation at some point...
>>> 
>>> I propose that we not repeat this discussion and instead, try to focus on 
>>> finishing.
>> 
>> If there isn't a consensus to do a DKIM-only feature, which seems to be the 
>> case, I agree, wrap up the few minor editorial issues and we're done.
>
>
>The two reasons I see against the DKIM-only feature are that it can be fixed 
>in SPF and a generic resistance to complications.
>
>If we add the feature, we should in any case exemplify how to fix SPF, saying 
>that doing so is safer, at least until all DMARC software has acquired the new 
>feature.  As the addition would be understood as a response to the known 
>vulnerability, it will likely be spread.
>
>As many of us consider it cleaner to have DMARC based on DKIM only, having 
>that possibility as an option is a first step in that direction anyway.  The 
>thesis that DKIM is enough has been opposed but the only cases where SPF saves 
>the day seem to be software bugs.  The DKIM-only feature would allow to probe 
>that thesis, which fixing SPF records would not.
>
What do we know now that we didn't know the last time we decided not to go DKIM 
only?  I'd argue there's nothing and endless relitigation of issues like this 
is making it impossible to actually accomplish what we're chartered to 
accomplish.

Let's either focus and finish or give up and close the group.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Alessandro Vesely]

On Fri 27/Oct/2023 12:34:11 +0200 John Levine wrote:

It appears that Scott Kitterman   said:
That is unfortunately true, but if we could decouple the DMARC from 
SPF, then at least we could fix the situation at some point...


I propose that we not repeat this discussion and instead, try to focus on 
finishing.


If there isn't a consensus to do a DKIM-only feature, which seems to be the case, 
I agree, wrap up the few minor editorial issues and we're done.



The two reasons I see against the DKIM-only feature are that it can be fixed in 
SPF and a generic resistance to complications.


If we add the feature, we should in any case exemplify how to fix SPF, saying 
that doing so is safer, at least until all DMARC software has acquired the new 
feature.  As the addition would be understood as a response to the known 
vulnerability, it will likely be spread.


As many of us consider it cleaner to have DMARC based on DKIM only, having that 
possibility as an option is a first step in that direction anyway.  The thesis 
that DKIM is enough has been opposed but the only cases where SPF saves the day 
seem to be software bugs.  The DKIM-only feature would allow to probe that 
thesis, which fixing SPF records would not.



Best
Ale
--



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Wei Chuang]

I  concur with what Doug mentioned.  As someone on the receiving end of bad
press due to an exploit of what I perceive to be weaknesses in the DMARC
standards particularly around depending on SPF [1], and then had to drop
everything to mitigate, I would suggest taking this opportunity to
strengthen DMARCbis.  After all, preventing From header spoofing is the
core of what DMARC is about.  As for why a new tag, I noted in [2], we see
a high degree of overlapping coverage in DKIM and SPF authentication, but
there is a small set of SPF only authentication that likely needs coverage,
and noted that different senders have different From header security needs
e.g. those that use cloud services really should only use DKIM but a very
small sender might not.  As noted, I proposed language [3] for DMARC to
enable this change, and at least on that thread there seemed to be
consensus.
-Wei

[1] There was an attack on BIMI starting on March 31.  An attacker was able
to exploit a large cloud provider that provides mail services for many well
known companies to forward a message with a spoofed From header.   That
message could obtain SPF authentication using the relay's IP SPF, thereby
getting a DMARC pass hence a BIMI pass.  Agreed with the earlier statement
that the fault here doesn't appear to lie with SPF domain owner as they
appeared to have followed reasonable practices.  Rather SPF relies upon IP
which is very often shared between multiple senders.  The Forward Pass
paper documents this very well:
https://www.sysnet.ucsd.edu/~voelker/pubs/forwarding-eurosp23.pdf
[2] https://mailarchive.ietf.org/arch/msg/dmarc/KeGbMfX91WJk_aziKsrRfI6AYkI/
I realized that the archived text version of tables there got munged, so
putting the key table back to format for text:
The following categorizes combination of SPF and DKIM authentication of
percentage of traffic that Gmail sees on a given day.  Of this traffic,
DKIM is not passing for 5.56% and of that there's SPF coverage for 4.78%
(86% of DKIM not passing).  A large cause for this is messages that were
not DKIM signed but could be validated with SPF at 3.91% (70% of DKIM not
passing).

ConcatSpfPassDkimAuthResults %
TRUE,PASS92.58%
TRUE,NEUTRAL 3.91%
FALSE,PASS   1.85%
FALSE,NEUTRAL0.72%
TRUE,FAIL0.69%
TRUE,TEMPERROR   0.17%
FALSE,FAIL   0.05%
FALSE,TEMPERROR  0.02%
TRUE,POLICY  0.00%
FALSE,POLICY 0.00%
Grand Total100.00%

[3] Initial "auth" tag proposal
https://mailarchive.ietf.org/arch/msg/dmarc/PDktxOYkB28k6ukLDgDqlp6NEGw/
and with comments rolled up
https://mailarchive.ietf.org/arch/msg/dmarc/oqcJoGfBCX0C3Y7yZzCga3k6sTs/

On Thu, Oct 26, 2023 at 5:27 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Like Ale, I thought the group had agreed to implement an auth=DKIM-only
> option of some type.
>
> I understood the motivation to be false pass created by malicious
> forwarding through a legitimate hosting platform.  Therefore  SPF precision
> is an unrelated issue.
>
> Doug
>
> On Thu, Oct 26, 2023, 5:46 PM Tero Kivinen  wrote:
>
>> John Levine writes:
>> > It appears that Scott Kitterman   said:
>> > >>* Is there consensus on moving ahead with the idea of a way to
>> indicate
>> > >>which authentication method(s) the Domain Owner wants Receivers to
>> use?  If
>> > >>so, it doesn't seem to be in the document yet.
>> > >
>> > >I haven't seen any valid case for it yet.  It adds complexity to
>> > >little or no benefit.
>> >
>> > Normally I am in favor of keeping stuff simple, but I think in this
>> case the
>> > argument for "DKIM only" is quite strong.
>>
>> Actually removing SPF completely from DMARC would simplyfy the
>> protocol a lot, and would solve several issues, where people use DMARC
>> with only SPF, or claim to do dmarc, but do filtering based on the SPF
>> records before getting to the actual email, thus not checking DKIM
>> records at all.
>>
>> If the DMARC would only use DKIM, that would make it clear that if you
>> want to publish DMARC records you needs to also use DKIM, and when
>> checking DMARC records you need to check verify DKIM signatures.
>>
>> Whether you do SPF in addition to that before or after would be local
>> implementation issue, and not part of the DMARC.
>>
>> There were people who wanted to keep SPF as part of the DMARC, who did
>> not even do DMARC, because the used SPF only as a first step of
>> filtering during the MAIL FROM phase (before being able to fetch DMARC
>> records, or checking DKIM signatures)...
>>
>> > There's the counterargument "so don't publish SPF" but it's on so
>> > many checklists that even though that would be a fine idea, it's not
>> > practical.
>>
>> That is unfortunately true, but if we could decouple the DMARC from
>> SPF, then at least we could fix the situation at some 

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Dotzero]

On Thu, Oct 26, 2023 at 8:25 PM Scott Kitterman 
wrote:

>
>
>
> I propose that we not repeat this discussion and instead, try to focus on
> finishing.
>
> Scott K
>


Agreed.  +1

Michael Hammer
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[John Levine]

It appears that Scott Kitterman   said:
>>That is unfortunately true, but if we could decouple the DMARC from
>>SPF, then at least we could fix the situation at some point... 
>
>I propose that we not repeat this discussion and instead, try to focus on 
>finishing.

If there isn't a consensus to do a DKIM-only feature, which seems to be the 
case,
I agree, wrap up the few minor editorial issues and we're done.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Douglas Foster]

Like Ale, I thought the group had agreed to implement an auth=DKIM-only
option of some type.

I understood the motivation to be false pass created by malicious
forwarding through a legitimate hosting platform.  Therefore  SPF precision
is an unrelated issue.

Doug

On Thu, Oct 26, 2023, 5:46 PM Tero Kivinen  wrote:

> John Levine writes:
> > It appears that Scott Kitterman   said:
> > >>* Is there consensus on moving ahead with the idea of a way to indicate
> > >>which authentication method(s) the Domain Owner wants Receivers to
> use?  If
> > >>so, it doesn't seem to be in the document yet.
> > >
> > >I haven't seen any valid case for it yet.  It adds complexity to
> > >little or no benefit.
> >
> > Normally I am in favor of keeping stuff simple, but I think in this case
> the
> > argument for "DKIM only" is quite strong.
>
> Actually removing SPF completely from DMARC would simplyfy the
> protocol a lot, and would solve several issues, where people use DMARC
> with only SPF, or claim to do dmarc, but do filtering based on the SPF
> records before getting to the actual email, thus not checking DKIM
> records at all.
>
> If the DMARC would only use DKIM, that would make it clear that if you
> want to publish DMARC records you needs to also use DKIM, and when
> checking DMARC records you need to check verify DKIM signatures.
>
> Whether you do SPF in addition to that before or after would be local
> implementation issue, and not part of the DMARC.
>
> There were people who wanted to keep SPF as part of the DMARC, who did
> not even do DMARC, because the used SPF only as a first step of
> filtering during the MAIL FROM phase (before being able to fetch DMARC
> records, or checking DKIM signatures)...
>
> > There's the counterargument "so don't publish SPF" but it's on so
> > many checklists that even though that would be a fine idea, it's not
> > practical.
>
> That is unfortunately true, but if we could decouple the DMARC from
> SPF, then at least we could fix the situation at some point...
> --
> kivi...@iki.fi
>
> ___
> 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] DMARCbis way forward: Do we need our session at IETF 118

[Scott Kitterman]

On October 26, 2023 9:46:04 PM UTC, Tero Kivinen  wrote:
>John Levine writes:
>> It appears that Scott Kitterman   said:
>> >>* Is there consensus on moving ahead with the idea of a way to indicate
>> >>which authentication method(s) the Domain Owner wants Receivers to use?  If
>> >>so, it doesn't seem to be in the document yet.
>> >
>> >I haven't seen any valid case for it yet.  It adds complexity to
>> >little or no benefit.  
>> 
>> Normally I am in favor of keeping stuff simple, but I think in this case the
>> argument for "DKIM only" is quite strong.
>
>Actually removing SPF completely from DMARC would simplyfy the
>protocol a lot, and would solve several issues, where people use DMARC
>with only SPF, or claim to do dmarc, but do filtering based on the SPF
>records before getting to the actual email, thus not checking DKIM
>records at all.
>
>If the DMARC would only use DKIM, that would make it clear that if you
>want to publish DMARC records you needs to also use DKIM, and when
>checking DMARC records you need to check verify DKIM signatures.
>
>Whether you do SPF in addition to that before or after would be local
>implementation issue, and not part of the DMARC.
>
>There were people who wanted to keep SPF as part of the DMARC, who did
>not even do DMARC, because the used SPF only as a first step of
>filtering during the MAIL FROM phase (before being able to fetch DMARC
>records, or checking DKIM signatures)...
>
>> There's the counterargument "so don't publish SPF" but it's on so
>> many checklists that even though that would be a fine idea, it's not
>> practical.
>
>That is unfortunately true, but if we could decouple the DMARC from
>SPF, then at least we could fix the situation at some point... 

I propose that we not repeat this discussion and instead, try to focus on 
finishing.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Tero Kivinen]

John Levine writes:
> It appears that Scott Kitterman   said:
> >>* Is there consensus on moving ahead with the idea of a way to indicate
> >>which authentication method(s) the Domain Owner wants Receivers to use?  If
> >>so, it doesn't seem to be in the document yet.
> >
> >I haven't seen any valid case for it yet.  It adds complexity to
> >little or no benefit.  
> 
> Normally I am in favor of keeping stuff simple, but I think in this case the
> argument for "DKIM only" is quite strong.

Actually removing SPF completely from DMARC would simplyfy the
protocol a lot, and would solve several issues, where people use DMARC
with only SPF, or claim to do dmarc, but do filtering based on the SPF
records before getting to the actual email, thus not checking DKIM
records at all.

If the DMARC would only use DKIM, that would make it clear that if you
want to publish DMARC records you needs to also use DKIM, and when
checking DMARC records you need to check verify DKIM signatures.

Whether you do SPF in addition to that before or after would be local
implementation issue, and not part of the DMARC.

There were people who wanted to keep SPF as part of the DMARC, who did
not even do DMARC, because the used SPF only as a first step of
filtering during the MAIL FROM phase (before being able to fetch DMARC
records, or checking DKIM signatures)...

> There's the counterargument "so don't publish SPF" but it's on so
> many checklists that even though that would be a fine idea, it's not
> practical.

That is unfortunately true, but if we could decouple the DMARC from
SPF, then at least we could fix the situation at some point... 
-- 
kivi...@iki.fi

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Alessandro Vesely]

On Wed 25/Oct/2023 16:01:01 +0200 Scott Kitterman wrote:

On October 25, 2023 1:37:55 PM UTC, John Levine  wrote:

It appears that Scott Kitterman   said:


I haven't seen any valid case for it yet.  It adds complexity to little or no benefit. 


[...]

There's the counterargument "so don't publish SPF" but it's on so many 
checklists
that even though that would be a fine idea, it's not practical.


Diving into the SPF angle, if someone has a 'legitimate' mail source that also 
sends spoofed mail for them, they can prefix the relevant mechanism with '?' so 
it produces a neutral rather than a pass result.  DMARC will ignore it then.  
Still solvable in SPF with no protocol change.



For example, change _o365spf.state.gov to

   "v=spf1 ?include:spf.protection.outlook.com -all"

It was a mistake to have a missing qualifier default to +.  Suggesting that the 
qualifier is optional implicitly depreciated the value of "pass".  But yes, 
that fix would work.


It is still possible to provide for an alternative way to fix it.  More 
complication for more flexibility.



Best
Ale
--



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Scott Kitterman]

On Wednesday, October 25, 2023 11:01:27 AM EDT Richard Clayton wrote:
> In message , Scott
> Kitterman  writes
> 
> >>> My reading of the discussion is:
> >>> 
> >>> 1. We did not have rough consensus to eliminate the use of SPF in DMARC.
> 
> sadly so, it would have been the right thing to do
> 
> >>> 2. We did not have rough consensus to complicate DMARC by having the
> >
> >publishing domain specify authentication methods.
> 
> hmm...  it does seem to be the best way of addressing #1
> 
> >The purported use case is "my SPF is so awful you can't trust it and at the
> >same time, so critical I still have to publish the record".  I don't think
> >that's a real thing.
> 
> there appear to be receivers who use SPF as a filtering mechanism to
> reject patently obvious forgeries -- and if SPF passes they then apply
> other mechanisms because they don't want to bother with DKIM  (I've seen
> posts to this effect -- their customers, their funeral)
> 
> not having an SPF record at all would mean that these receivers would
> not be able to do that filtering (and the lack of SPF might adversely
> affect various heuristics for determining how email should be treated)
> 
> viz: there is an edge case for senders to continue to publish SPF even
> when it almost useless (it stops people forging mail from a different
> cloud, but not from the one that they use)
> 
> if that is so, then senders need to be able to tell all the receivers
> who do believe in the value of DKIM (and there are a lot of those) "take
> no notice of my SPF record" ... so DMARCbis should support that
> 
> Note that if BIMI is involved the SPF will be ignored anyway (and the
> documentation might even say that RSN)
> 
> >If your SPF is unreliable, fix it or delete it.  Not a DMARC problem.
> 
> senders using clouds to spin up and spin down resources depending on
> demand will struggle to "fix it"  ...  that's why it was so widely drawn
> in the first place. Senders using shared IPs at ESPs are also not in a
> position to "fix it" -- they can only hope that the ESP correctly
> polices what is being sent by each particular customer.

Modifying their SPF record to include '?' for the suspect mechanisms is the 
exact technical solution to this problem.  It has no impact on rejecting 
messages that fail SPF and keeps such mail from passing DMARC.

The solution to bad SPF deployments is fixing them.

Scott K



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Scott Kitterman]

On Wednesday, October 25, 2023 10:46:09 AM EDT Emanuel Schorsch wrote:
> > >There's the counterargument "so don't publish SPF" but it's on so many
> > 
> > checklists
> > 
> > >that even though that would be a fine idea, it's not practical.
> > 
> > Diving into the SPF angle, if someone has a 'legitimate' mail source that
> > also sends spoofed mail for them, they can prefix the relevant mechanism
> > with '?' so it produces a neutral rather than a pass result.  DMARC will
> > ignore it then.  Still solvable in SPF with no protocol change.
> > 
> > These sources are effectively open relays (not literally, but
> > practically).  This isn't a problem that should be solved by a protocol
> > change in DMARC.
> 
> I too had thought there was consensus on this issue. I think in this case
> it is appropriate for a protocol change. Senders today do not currently
> have a way to express "ignore my SPF when evaluating DMARC". Adding that to
> the protocol is necessary to give them that choice. We have seen hundreds
> of senders affected by this issue and it is not acceptable for them to turn
> off SPF because there are a variety of receivers out there with varying
> requirements and turning off SPF entirely might have a negative impact. It
> is more than acceptable for them to say: ignore SPF from the perspective of
> DMARC.

And then where's DMARC when the demand comes up to ignore DKIM because of the 
impacts of DKIM replay attacks?

To me this is similar to the multiple suggestions over the years to add an "I 
really mean it" flag to SPF for records that end in -all and it's an equally 
'good' idea.  This is entirely fixable within SPF as the message you are 
replying to describes.

Scott K



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Richard Clayton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In message , Scott
Kitterman  writes

>>> My reading of the discussion is:
>>> 
>>> 1. We did not have rough consensus to eliminate the use of SPF in DMARC.

sadly so, it would have been the right thing to do

>>> 2. We did not have rough consensus to complicate DMARC by having the 
>publishing domain specify authentication methods.

hmm...  it does seem to be the best way of addressing #1

>The purported use case is "my SPF is so awful you can't trust it and at the 
>same 
>time, so critical I still have to publish the record".  I don't think that's a 
>real thing.

there appear to be receivers who use SPF as a filtering mechanism to
reject patently obvious forgeries -- and if SPF passes they then apply
other mechanisms because they don't want to bother with DKIM  (I've seen
posts to this effect -- their customers, their funeral)

not having an SPF record at all would mean that these receivers would
not be able to do that filtering (and the lack of SPF might adversely
affect various heuristics for determining how email should be treated)

viz: there is an edge case for senders to continue to publish SPF even
when it almost useless (it stops people forging mail from a different
cloud, but not from the one that they use)

if that is so, then senders need to be able to tell all the receivers
who do believe in the value of DKIM (and there are a lot of those) "take
no notice of my SPF record" ... so DMARCbis should support that

Note that if BIMI is involved the SPF will be ignored anyway (and the
documentation might even say that RSN) 

>If your SPF is unreliable, fix it or delete it.  Not a DMARC problem.

senders using clouds to spin up and spin down resources depending on
demand will struggle to "fix it"  ...  that's why it was so widely drawn
in the first place. Senders using shared IPs at ESPs are also not in a
position to "fix it" -- they can only hope that the ESP correctly
polices what is being sent by each particular customer.

- -- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.7.1

iQA/AwUBZTktx92nQQHFxEViEQLZfwCgrWwC2PLCvHV8I9aHLE5XVZLZGTQAnjar
ThGQVjdL/8CrteVWGe3KaNTO
=BqvR
-END PGP SIGNATURE-

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Emanuel Schorsch]

>
> >There's the counterargument "so don't publish SPF" but it's on so many
> checklists
> >that even though that would be a fine idea, it's not practical.
>
> Diving into the SPF angle, if someone has a 'legitimate' mail source that
> also sends spoofed mail for them, they can prefix the relevant mechanism
> with '?' so it produces a neutral rather than a pass result.  DMARC will
> ignore it then.  Still solvable in SPF with no protocol change.
>
> These sources are effectively open relays (not literally, but
> practically).  This isn't a problem that should be solved by a protocol
> change in DMARC.
>

I too had thought there was consensus on this issue. I think in this case
it is appropriate for a protocol change. Senders today do not currently
have a way to express "ignore my SPF when evaluating DMARC". Adding that to
the protocol is necessary to give them that choice. We have seen hundreds
of senders affected by this issue and it is not acceptable for them to turn
off SPF because there are a variety of receivers out there with varying
requirements and turning off SPF entirely might have a negative impact. It
is more than acceptable for them to say: ignore SPF from the perspective of
DMARC.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Scott Kitterman]

On October 25, 2023 1:37:55 PM UTC, John Levine  wrote:
>It appears that Scott Kitterman   said:
>>>* Is there consensus on moving ahead with the idea of a way to indicate
>>>which authentication method(s) the Domain Owner wants Receivers to use?  If
>>>so, it doesn't seem to be in the document yet.
>>
>>I haven't seen any valid case for it yet.  It adds complexity to little or no 
>>benefit. 
>
>Normally I am in favor of keeping stuff simple, but I think in this case the
>argument for "DKIM only" is quite strong.  People whose opinion I trust tell
>me that so many SPF records include so many large clouds that in practice
>an SPF pass no longer tells you anything useful.
>
>There's the counterargument "so don't publish SPF" but it's on so many 
>checklists
>that even though that would be a fine idea, it's not practical.

Diving into the SPF angle, if someone has a 'legitimate' mail source that also 
sends spoofed mail for them, they can prefix the relevant mechanism with '?' so 
it produces a neutral rather than a pass result.  DMARC will ignore it then.  
Still solvable in SPF with no protocol change.

These sources are effectively open relays (not literally, but practically).  
This isn't a problem that should be solved by a protocol change in DMARC.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[John Levine]

It appears that Scott Kitterman   said:
>>* Is there consensus on moving ahead with the idea of a way to indicate
>>which authentication method(s) the Domain Owner wants Receivers to use?  If
>>so, it doesn't seem to be in the document yet.
>
>I haven't seen any valid case for it yet.  It adds complexity to little or no 
>benefit. 

Normally I am in favor of keeping stuff simple, but I think in this case the
argument for "DKIM only" is quite strong.  People whose opinion I trust tell
me that so many SPF records include so many large clouds that in practice
an SPF pass no longer tells you anything useful.

There's the counterargument "so don't publish SPF" but it's on so many 
checklists
that even though that would be a fine idea, it's not practical.

>>* Given some of the stuff we're hearing in the wings about the utility of
>>ARC, do we want to talk about it in -bis at all? 

>ARC solves nothing on its own.  ARC plus a list of senders I trust not to lie 
>to me is quite useful.  I don't
>think it can be raised to a more formal part of DMARC since its utility if 
>entirely dependent on
>non-standardized (and almost certainly non-standardizable) special sauce.

Agreed.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Dotzero]

On Wed, Oct 25, 2023 at 8:56 AM Scott Kitterman 
wrote:

>
>
> On October 25, 2023 11:56:25 AM UTC, Alessandro Vesely 
> wrote:
> >On Wed 25/Oct/2023 13:12:32 +0200 Barry Leiba wrote:
>  * Is there consensus on moving ahead with the idea of a way to
> indicate which authentication method(s) the Domain Owner wants Receivers to
> use?  If so, it doesn't seem to be in the document yet.
> >>>
> >>> My recall is that we want to limit DMARC evaluation to DKIM only, for
> the edge cases of domains with over-wide SPF policies, since they proved to
> be vulnerable to false DMARC pass.  The WG discussed the possibility to
> also require both methods to limit replay, and concluded that the idea was
> a foot gun.  Hence the WG agreed on the comma syntax.
> >>
> >> My reading of the discussion is:
> >>
> >> 1. We did not have rough consensus to eliminate the use of SPF in DMARC.
> >
> >
> >Yes.
> >
> >
> >> 2. We did not have rough consensus to complicate DMARC by having the
> publishing domain specify authentication methods.
> >
> >
> >One thread started here:
> >https://mailarchive.ietf.org/arch/msg/dmarc/PDktxOYkB28k6ukLDgDqlp6NEGw/
> >
> >It ends up with Wei recapitulating the thread and summarizing the changes
> to the draft.  No objections.  I expected those changes to be carried out.
> >
> >
> >> Ale, you're saying that my reading on (2) is wrong, yes?  Can you
> provide support for that?
> >
> >
> >I had only seen Scott's reading, which surprised me.  After you and
> Michael hold that no agreement was reached, I begin to doubt of my reading
> myself.
> >
> >In particular, since there is a paper[*] showing how a "spoofed email
> >purporting to be b...@state.gov is delivered to a Gmail user’s inbox
> with no warning indicators", Wei's argument seemed to be fully reasonable.
> >
> >What outstanding objections were there?
>
> The purported use case is "my SPF is so awful you can't trust it and at
> the same time, so critical I still have to publish the record".  I don't
> think that's a real thing.
>
> If your SPF is unreliable, fix it or delete it.  Not a DMARC problem.
>

+1

We need to stop confusing operational/implementation issues on the part of
some with issues that reflect poor logic in a standard.

Michael Hammer
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Scott Kitterman]

On October 25, 2023 11:56:25 AM UTC, Alessandro Vesely  wrote:
>On Wed 25/Oct/2023 13:12:32 +0200 Barry Leiba wrote:
 * Is there consensus on moving ahead with the idea of a way to indicate 
 which authentication method(s) the Domain Owner wants Receivers to use?  
 If so, it doesn't seem to be in the document yet.
>>> 
>>> My recall is that we want to limit DMARC evaluation to DKIM only, for the 
>>> edge cases of domains with over-wide SPF policies, since they proved to be 
>>> vulnerable to false DMARC pass.  The WG discussed the possibility to also 
>>> require both methods to limit replay, and concluded that the idea was a 
>>> foot gun.  Hence the WG agreed on the comma syntax.
>> 
>> My reading of the discussion is:
>> 
>> 1. We did not have rough consensus to eliminate the use of SPF in DMARC.
>
>
>Yes.
>
>
>> 2. We did not have rough consensus to complicate DMARC by having the 
>> publishing domain specify authentication methods.
>
>
>One thread started here:
>https://mailarchive.ietf.org/arch/msg/dmarc/PDktxOYkB28k6ukLDgDqlp6NEGw/
>
>It ends up with Wei recapitulating the thread and summarizing the changes to 
>the draft.  No objections.  I expected those changes to be carried out.
>
>
>> Ale, you're saying that my reading on (2) is wrong, yes?  Can you provide 
>> support for that?
>
>
>I had only seen Scott's reading, which surprised me.  After you and Michael 
>hold that no agreement was reached, I begin to doubt of my reading myself.
>
>In particular, since there is a paper[*] showing how a "spoofed email
>purporting to be b...@state.gov is delivered to a Gmail user’s inbox with no 
>warning indicators", Wei's argument seemed to be fully reasonable.
>
>What outstanding objections were there?

The purported use case is "my SPF is so awful you can't trust it and at the 
same time, so critical I still have to publish the record".  I don't think 
that's a real thing.

If your SPF is unreliable, fix it or delete it.  Not a DMARC problem.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Alessandro Vesely]

On Wed 25/Oct/2023 13:12:32 +0200 Barry Leiba wrote:
* Is there consensus on moving ahead with the idea of a way to indicate 
which authentication method(s) the Domain Owner wants Receivers to use?  If 
so, it doesn't seem to be in the document yet.


My recall is that we want to limit DMARC evaluation to DKIM only, for the edge 
cases of domains with over-wide SPF policies, since they proved to be 
vulnerable to false DMARC pass.  The WG discussed the possibility to also 
require both methods to limit replay, and concluded that the idea was a foot 
gun.  Hence the WG agreed on the comma syntax.


My reading of the discussion is:

1. We did not have rough consensus to eliminate the use of SPF in DMARC.



Yes.


2. We did not have rough consensus to complicate DMARC by having the 
publishing domain specify authentication methods.



One thread started here:
https://mailarchive.ietf.org/arch/msg/dmarc/PDktxOYkB28k6ukLDgDqlp6NEGw/

It ends up with Wei recapitulating the thread and summarizing the changes to 
the draft.  No objections.  I expected those changes to be carried out.



Ale, you're saying that my reading on (2) is wrong, yes?  Can you 
provide support for that?



I had only seen Scott's reading, which surprised me.  After you and Michael 
hold that no agreement was reached, I begin to doubt of my reading myself.


In particular, since there is a paper[*] showing how a "spoofed email
purporting to be b...@state.gov is delivered to a Gmail user’s inbox with no 
warning indicators", Wei's argument seemed to be fully reasonable.


What outstanding objections were there?


Best
Ale
--

[*] Enze Liu et al.  "Forward Pass: On the Security Implications of
Email Forwarding Mechanism and Policy", https://arxiv.org/abs/2302.07287




___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Dotzero]

On Wed, Oct 25, 2023 at 7:12 AM Barry Leiba  wrote:

> > > * Is there consensus on moving ahead with the idea of a way to indicate
> > > which authentication method(s) the Domain Owner wants Receivers to
> use?  If
> > > so, it doesn't seem to be in the document yet.
> >
> > My recall is that we want to limit DMARC evaluation to DKIM only, for
> the edge
> > cases of domains with over-wide SPF policies, since they proved to be
> > vulnerable to false DMARC pass.  The WG discussed the possibility to also
> > require both methods to limit replay, and concluded that the idea was a
> foot
> > gun.  Hence the WG agreed on the comma syntax.
>
> My reading of the discussion is:
>
> 1. We did not have rough consensus to eliminate the use of SPF in DMARC.
>

+1


> 2. We did not have rough consensus to complicate DMARC by having the
> publishing domain specify authentication methods.
>

+1


> Ale, you're saying that my reading on (2) is wrong, yes?  Can you
> provide support for that?
>
>
Mi chael Hammer
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Barry Leiba]

> > * Is there consensus on moving ahead with the idea of a way to indicate
> > which authentication method(s) the Domain Owner wants Receivers to use?  If
> > so, it doesn't seem to be in the document yet.
>
> My recall is that we want to limit DMARC evaluation to DKIM only, for the edge
> cases of domains with over-wide SPF policies, since they proved to be
> vulnerable to false DMARC pass.  The WG discussed the possibility to also
> require both methods to limit replay, and concluded that the idea was a foot
> gun.  Hence the WG agreed on the comma syntax.

My reading of the discussion is:

1. We did not have rough consensus to eliminate the use of SPF in DMARC.

2. We did not have rough consensus to complicate DMARC by having the
publishing domain specify authentication methods.

Ale, you're saying that my reading on (2) is wrong, yes?  Can you
provide support for that?

Barry

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Alessandro Vesely]

On Wed 25/Oct/2023 05:38:01 +0200 Murray S. Kucherawy wrote:

On Tue, Oct 24, 2023 at 11:15 AM Barry Leiba  wrote:


2. Do we have what we need to finish up the DMARCbis document, and
should the chairs cancel the session at 118?


A few questions, but they don't demand in-person time if we want to just 
deal with them on the list:


* Is there consensus on moving ahead with the idea of a way to indicate 
which authentication method(s) the Domain Owner wants Receivers to use?  If 
so, it doesn't seem to be in the document yet.



My recall is that we want to limit DMARC evaluation to DKIM only, for the edge 
cases of domains with over-wide SPF policies, since they proved to be 
vulnerable to false DMARC pass.  The WG discussed the possibility to also 
require both methods to limit replay, and concluded that the idea was a foot 
gun.  Hence the WG agreed on the comma syntax.



* Given some of the stuff we're hearing in the wings about the utility of 
ARC, do we want to talk about it in -bis at all?  The original plan (I 
thought) was that if it turned out to be high signal, we could add it as a 
third supported method.  I'm hearing positive value from a couple of 
operators, but nothing of the form "Yes, this solves the DMARC problem with 
lists."



ARC was barely specified.  A protocol to regulate in which cases it overrides 
DMARC was not specified.  A reporting mechanism was not specified.  These 
issues belong to the charter and I hope the WG will tackle them, after DMARCbis 
last call.  To merge an ARC applicability statement into DMARCbis would distort 
it into an experimental thing, thereby failing to standardize it.



Best
Ale
--




___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Alessandro Vesely]

On Tue 24/Oct/2023 20:15:22 +0200 Barry Leiba wrote:


2. Do we have what we need to finish up the DMARCbis document, and
should the chairs cancel the session at 118?



IMHO this one.


Best
Ale
--




___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Scott Kitterman]

On October 25, 2023 3:38:01 AM UTC, "Murray S. Kucherawy"  
wrote:
>On Tue, Oct 24, 2023 at 11:15 AM Barry Leiba 
>wrote:
>
>> Now that we have a consensus call on the main issue that has remained open:
>>
>> 1. Do we need to retain our session at IETF 118 and discuss this (or
>> something else) further?
>>
>> ...or...
>>
>> 2. Do we have what we need to finish up the DMARCbis document, and
>> should the chairs cancel the session at 118?
>>
>
>A few questions, but they don't demand in-person time if we want to just
>deal with them on the list:
>
>* Is there consensus on moving ahead with the idea of a way to indicate
>which authentication method(s) the Domain Owner wants Receivers to use?  If
>so, it doesn't seem to be in the document yet.

I haven't seen any valid case for it yet.  It adds complexity to little or no 
benefit.  Although sometimes it seems like complexity for complexities' sake is 
the IETF's stoke and trade, I believe we ought to try and avoid adding any more 
than we have to in order to meet our chartered mandate.


>* Given some of the stuff we're hearing in the wings about the utility of
>ARC, do we want to talk about it in -bis at all?  The original plan (I
>thought) was that if it turned out to be high signal, we could add it as a
>third supported method.  I'm hearing positive value from a couple of
>operators, but nothing of the form "Yes, this solves the DMARC problem with
>lists."

ARC solves nothing on its own.  ARC plus a list of senders I trust not to lie 
to me is quite useful.  I don't think it can be raised to a more formal part of 
DMARC since its utility if entirely dependent on non-standardized (and almost 
certainly non-standardizable) special sauce.


>* Any open issues in the tracker that would benefit from face time?
>
>I'm happy to repeat my 117 rant at 118.  I don't think much has changed
>since then, which makes some of those points more urgent... ;-)
>
>-MSK, participating

I don't think a meeting would help with either of those.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Murray S. Kucherawy]

On Tue, Oct 24, 2023 at 11:15 AM Barry Leiba 
wrote:

> Now that we have a consensus call on the main issue that has remained open:
>
> 1. Do we need to retain our session at IETF 118 and discuss this (or
> something else) further?
>
> ...or...
>
> 2. Do we have what we need to finish up the DMARCbis document, and
> should the chairs cancel the session at 118?
>

A few questions, but they don't demand in-person time if we want to just
deal with them on the list:

* Is there consensus on moving ahead with the idea of a way to indicate
which authentication method(s) the Domain Owner wants Receivers to use?  If
so, it doesn't seem to be in the document yet.

* Given some of the stuff we're hearing in the wings about the utility of
ARC, do we want to talk about it in -bis at all?  The original plan (I
thought) was that if it turned out to be high signal, we could add it as a
third supported method.  I'm hearing positive value from a couple of
operators, but nothing of the form "Yes, this solves the DMARC problem with
lists."

* Any open issues in the tracker that would benefit from face time?

I'm happy to repeat my 117 rant at 118.  I don't think much has changed
since then, which makes some of those points more urgent... ;-)

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Hector Santos]

On 10/24/2023 2:15 PM, Barry Leiba wrote:

Now that we have a consensus call on the main issue that has remained open:

1. Do we need to retain our session at IETF 118 and discuss this (or
something else) further?

...or...

2. Do we have what we need to finish up the DMARCbis document, and
should the chairs cancel the session at 118?


I think #2  is best, imto.DMARC and DMARCbis will remain a processing 
overhead for logging, but no honoring of policies. I have yet to see 
any consistency. No faith in this protocol. It can not be considered a 
deterministic protocol. With all the debate on lookup, I still don't 
understand what is expected. Would be nice to see some simple pseudo 
code for the new logic. But why? Nothing deterministic about it to say 
- REJECT with confidence.


SPF is still king here though .


Oh, and...

3. Is there something else (such as the reporting documents) that we
should use the time at 118 to discuss?  Or can we continue with those
on the mailing list for now?  My sense is that aggregate reporting, at
least, is just about ready to go and doesn't need the face-to-face
time.


Primary technical problem is inconsistency in reading the report formats.

I want to know the following in a report:

Which domain? Who try to use it?  What was return path, the IP and 
principle DKIM identities, if you got that far?


I still won't know what I will gain but I do hope the receivers honor 
my policies especially for SPF because I am honoring SPF rejects on 
the receiver side.


SPF remains the only protocol I honor 100% and according to my 
business site sites, this month total rejects are 34% SPF!


If anything, I get DMARC reports but I learn nothing from them.

--
HLS___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

[Barry Leiba]

Now that we have a consensus call on the main issue that has remained open:

1. Do we need to retain our session at IETF 118 and discuss this (or
something else) further?

...or...

2. Do we have what we need to finish up the DMARCbis document, and
should the chairs cancel the session at 118?

Oh, and...

3. Is there something else (such as the reporting documents) that we
should use the time at 118 to discuss?  Or can we continue with those
on the mailing list for now?  My sense is that aggregate reporting, at
least, is just about ready to go and doesn't need the face-to-face
time.

Barry

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc