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] DMARC session at IETF 118

[Wei Chuang]

I'd vote for discussing the "auth=" tag proposal at IETF-118, and I can
participate remotely.  Discussing this on the mailing list is easier, but
will be drawn out as it's harder to understand if there is consensus one
way or the other.  The advantage is that this will time box the discussion
and I've heard many voices wanting closure so that DMARCbis can be
published.
-Wei

On Sat, Oct 28, 2023 at 11:02 AM Scott Kitterman 
wrote:

>
>
> On October 28, 2023 5:38:00 PM UTC, Barry Leiba 
> wrote:
> >I'm starting this in a separate thread that I want to keep for ONLY
> >the following question:
> >
> >Do we want to use the session we have scheduled at IETF 118 to talk
> >about the issue that clearly is still in discussion about adding a tag
> >to specify which authentication mechanism(s) to use when evaluating
> >DMARC?
> >
> >Or shall I cancel the 118 session and just let the discussion continue
> >on the mailing list?
> >
> >And being clear here: the "eliminate SPF entirely" suggestion is
> >definitely out, failing rough consensus.  We're *only* talking about
> >the suggestion to add a tag to specify what the sender wants.
> >
> I think cancel the meeting and keep the discussion on the ML.
>
> Scott K
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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] DMARC session at IETF 118

[Scott Kitterman]

On October 28, 2023 5:38:00 PM UTC, Barry Leiba  wrote:
>I'm starting this in a separate thread that I want to keep for ONLY
>the following question:
>
>Do we want to use the session we have scheduled at IETF 118 to talk
>about the issue that clearly is still in discussion about adding a tag
>to specify which authentication mechanism(s) to use when evaluating
>DMARC?
>
>Or shall I cancel the 118 session and just let the discussion continue
>on the mailing list?
>
>And being clear here: the "eliminate SPF entirely" suggestion is
>definitely out, failing rough consensus.  We're *only* talking about
>the suggestion to add a tag to specify what the sender wants.
>
I think cancel the meeting and keep the discussion on the ML.

Scott K

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

[dmarc-ietf] DMARC session at IETF 118

[Barry Leiba]

I'm starting this in a separate thread that I want to keep for ONLY
the following question:

Do we want to use the session we have scheduled at IETF 118 to talk
about the issue that clearly is still in discussion about adding a tag
to specify which authentication mechanism(s) to use when evaluating
DMARC?

Or shall I cancel the 118 session and just let the discussion continue
on the mailing list?

And being clear here: the "eliminate SPF entirely" suggestion is
definitely out, failing rough consensus.  We're *only* talking about
the suggestion to add a tag to specify what the sender wants.

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

[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