Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

[Murray S. Kucherawy]

On Fri, Jun 9, 2023 at 8:49 AM Alessandro Vesely  wrote:

> On Fri 09/Jun/2023 16:07:07 +0200 Murray S. Kucherawy wrote:
> > And signing software shouldn't be mutating messages ever (other than
> adding
> > signatures, of course).
>
> Section 5.3, Normalize the Message to Prevent Transport Conversions, gives
> different advice.  UTF-8, though, seems to be subject to mutating
> fashions;
> conversion to 7-bit form, IMHO, makes sense only if it is base64.  Quoted
> printable is messy and prevents recovery after MLM transformation.
>

You were previously talking about inserting ">" before a line starting
"From ", which is typically done on delivery when writing to an
mbox-formatted mailbox file, because in that format, "From " at the front
of a line has a specific meaning (i.e., "this is a new message").  If that
insertion is happening in transport, then a local mailbox convention is
leaking out into the transport environment, which means something is
misconfigured, and all bets are off.

In any case, it is not a transport conversion anticipated by the section
you're quoting, so I've no idea why a DKIM signer might opt to handle it
specially.

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

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

[Barry Leiba]

1. It is out of the scope of our charter to make any changes to SPF,
and that would include making it obsolete or Historic.

2. It is within the scope of our charter to make changes to DMARC, and
that would include removing SPF evaluation from it.  During the
process of making changes to DMARC we can also choose to change the
version number (or not).

We're discussing (2).  We will not discuss (1) at all, in any way.

Barry

On Fri, Jun 9, 2023 at 8:55 PM Hector Santos
 wrote:
>
> Barry,
>
> Whoa! Take it easy.
>
> We are on the DMARC2 thread per topic - a proposal. Not anything for the 
> current DMARCbis.
>
> Is the chair suggesting the current charter for DMARCbis should change to 
> remove SPF? Was the charter changed for this?
>
> To be clear, DMARC2 is not DMARCbis right now, are you wishing this now?
>
> Hector
>
>
> > On Jun 9, 2023, at 8:27 PM, Barry Leiba  wrote:
> >
> > Hector, did you not understand this?:
> >
> >>> We will *not* consider what should happen to
> >>> SPF outside of DMARC, and any discussion of that is *out of scope* for
> >>> this working group under its current charter.
> >
> > Please stop discussing it.
> >
> > Barry
> >
> > On Fri, Jun 9, 2023 at 8:23 PM Hector Santos  wrote:
> >>
> >>> On Jun 9, 2023, at 4:41 AM, Barry Leiba  wrote:
> >>>
> >>> Repeating this one point as chair, to make it absolutely clear:
> >>>
> >>> The proposal we're discussing is removing SPF authentication from
> >>> DMARC evaluation *only*.  We will *not* consider what should happen to
> >>> SPF outside of DMARC, and any discussion of that is *out of scope* for
> >>> this working group under its current charter.
> >>>
> >>> Barry, as chair
> >>
> >> For the record,  from a long time SMTP implementer standpoint, DMARC would 
> >> be ignored, dropped, turned off, etc first before any consideration to 
> >> stop SPF support.   As a Transporter, SPF works. As an Administrator - 
> >> ADSP, I mean “Supper ADSP” aka DMARC has been horrible.  I, and most 
> >> people, could easily deprecate Wildcat! DMARC with no harm and fact, less 
> >> harm because the false positives will disappear.  My product add-on for 
> >> wcSMTP, wcDMARC, never did honor the p=reject|quarantine. It was left for 
> >> filters and no one hard any confidence to make it work.
> >>
> >> SPF on the other hand, I don’t see dropped in the name of DMARC.  So if 
> >> it’s about sparate, but not abandon, that I can support - because it is 
> >> already separate.  SPF preempts DMARC or any Payload protocol..
> >>
> >> Thanks
> >>
> >
> > ___
> > 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] DMARC2 & SPF Dependency Removal

[Hector Santos]

Barry,

Whoa! Take it easy.  

We are on the DMARC2 thread per topic - a proposal. Not anything for the 
current DMARCbis. 

Is the chair suggesting the current charter for DMARCbis should change to 
remove SPF? Was the charter changed for this?

To be clear, DMARC2 is not DMARCbis right now, are you wishing this now?

Hector


> On Jun 9, 2023, at 8:27 PM, Barry Leiba  wrote:
> 
> Hector, did you not understand this?:
> 
>>> We will *not* consider what should happen to
>>> SPF outside of DMARC, and any discussion of that is *out of scope* for
>>> this working group under its current charter.
> 
> Please stop discussing it.
> 
> Barry
> 
> On Fri, Jun 9, 2023 at 8:23 PM Hector Santos  wrote:
>> 
>>> On Jun 9, 2023, at 4:41 AM, Barry Leiba  wrote:
>>> 
>>> Repeating this one point as chair, to make it absolutely clear:
>>> 
>>> The proposal we're discussing is removing SPF authentication from
>>> DMARC evaluation *only*.  We will *not* consider what should happen to
>>> SPF outside of DMARC, and any discussion of that is *out of scope* for
>>> this working group under its current charter.
>>> 
>>> Barry, as chair
>> 
>> For the record,  from a long time SMTP implementer standpoint, DMARC would 
>> be ignored, dropped, turned off, etc first before any consideration to stop 
>> SPF support.   As a Transporter, SPF works. As an Administrator - ADSP, I 
>> mean “Supper ADSP” aka DMARC has been horrible.  I, and most people, could 
>> easily deprecate Wildcat! DMARC with no harm and fact, less harm because the 
>> false positives will disappear.  My product add-on for wcSMTP, wcDMARC, 
>> never did honor the p=reject|quarantine. It was left for filters and no one 
>> hard any confidence to make it work.
>> 
>> SPF on the other hand, I don’t see dropped in the name of DMARC.  So if it’s 
>> about sparate, but not abandon, that I can support - because it is already 
>> separate.  SPF preempts DMARC or any Payload protocol..
>> 
>> Thanks
>> 
> 
> ___
> 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] DMARC2 & SPF Dependency Removal

[Barry Leiba]

Hector, did you not understand this?:

>> We will *not* consider what should happen to
>> SPF outside of DMARC, and any discussion of that is *out of scope* for
>> this working group under its current charter.

Please stop discussing it.

Barry

On Fri, Jun 9, 2023 at 8:23 PM Hector Santos  wrote:
>
> > On Jun 9, 2023, at 4:41 AM, Barry Leiba  wrote:
> >
> > Repeating this one point as chair, to make it absolutely clear:
> >
> > The proposal we're discussing is removing SPF authentication from
> > DMARC evaluation *only*.  We will *not* consider what should happen to
> > SPF outside of DMARC, and any discussion of that is *out of scope* for
> > this working group under its current charter.
> >
> > Barry, as chair
>
> For the record,  from a long time SMTP implementer standpoint, DMARC would be 
> ignored, dropped, turned off, etc first before any consideration to stop SPF 
> support.   As a Transporter, SPF works. As an Administrator - ADSP, I mean 
> “Supper ADSP” aka DMARC has been horrible.  I, and most people, could easily 
> deprecate Wildcat! DMARC with no harm and fact, less harm because the false 
> positives will disappear.  My product add-on for wcSMTP, wcDMARC, never did 
> honor the p=reject|quarantine. It was left for filters and no one hard any 
> confidence to make it work.
>
> SPF on the other hand, I don’t see dropped in the name of DMARC.  So if it’s 
> about sparate, but not abandon, that I can support - because it is already 
> separate.  SPF preempts DMARC or any Payload protocol..
>
> Thanks
>

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

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

[Hector Santos]

> On Jun 9, 2023, at 4:41 AM, Barry Leiba  > wrote:
> 
> Repeating this one point as chair, to make it absolutely clear:
> 
> The proposal we're discussing is removing SPF authentication from
> DMARC evaluation *only*.  We will *not* consider what should happen to
> SPF outside of DMARC, and any discussion of that is *out of scope* for
> this working group under its current charter.
> 
> Barry, as chair

For the record,  from a long time SMTP implementer standpoint, DMARC would be 
ignored, dropped, turned off, etc first before any consideration to stop SPF 
support.   As a Transporter, SPF works. As an Administrator - ADSP, I mean 
“Supper ADSP” aka DMARC has been horrible.  I, and most people, could easily 
deprecate Wildcat! DMARC with no harm and fact, less harm because the false 
positives will disappear.  My product add-on for wcSMTP, wcDMARC, never did 
honor the p=reject|quarantine. It was left for filters and no one hard any 
confidence to make it work.

SPF on the other hand, I don’t see dropped in the name of DMARC.  So if it’s 
about sparate, but not abandon, that I can support - because it is already 
separate.  SPF preempts DMARC or any Payload protocol..

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

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

[Barry Leiba]

Thanks for the follow-up, Scott.

> It's not a case of I've seen a few failures, it's consistent (all I can say
> for certain is that it was as I no longer have access to this data).  It was
> consistent across time and providers.  At scale, DKIM would always have a
> fraction of a percent failure rate, while SPF would not (for direct
> connections
...
> The leads to a situation where the DMARC pass rate for direct connections
> would vary depending on if SPF was included:
>
> DKIM only: ~99.5%
> DKIM + SPF: ~100%
> SPF only: ~100%

That's interesting and disturbing if it remains consistent.
Theoretically, DKIM should *never* fail when SPF succeeds, so if
that's happening it means there is:
1. bad signing software,
2. bad verifying software,
3. misconfiguration somewhere,
...or a combination of those three.

I would *really* like to see a current study of this, because I think
it's critical for the future viability of DMARC, whether or not we
accept the proposal to remove SPF.  If DKIM is not working reliably
when it should, we absolutely need to understand why and work on
getting it fixed if we can.  If there used to be problems that do not
currently exist, we need to understand that as well, so we can make
current arguments with currently accurate data.  Either way, we need
to know what's really happening.

Are there working group participants who can do this sort of
evaluation, not just giving numbers but also analyzing why DKIM
failures happened when they should not have?

Thanks again, Scott,
Barry

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

Re: [dmarc-ietf] version bump to DMARC2

[Barry Leiba]

Keep in mind that we have looked at this extensively, and what we've
found is this:

1. Almost all [1] of the DMARC senders out there will see the same
results when recipients look them up using the tree walk as they have
using the PSL.  In other words, the change will be different an
*extremely* small set of DMARC domains.

2. In *all* -- by that I mean 100% -- of the cases that we've actually
*seen* where there's a difference, the difference is *better*: that
is, the difference is a better reflection of the intent of the sending
domain.

3. We can find theoretical cases where the tree walk will be *worse*:
that is, where the PSL is a better reflection of the intent than the
tree walk is.  But *all* of these are theoretical, and we have not
found *any* such cases that actually exist in the real world.  It is,
though, possible that they do exist.

Emil, given those three points, do you still think you need to be
concerned about the risk of making the change?

Barry

[1] In mathematics, we use "almost all" as an actual technical term
that applies to an infinite set and means "all but a finite number",
since removing a finite number of entries from an infinite set still
leaves an infinite set.  That's kind of what I mean here.  That is,
the vast, vast, VAST majority.

On Sat, Jun 10, 2023 at 12:26 AM Emil Gustafsson
 wrote:
>
> Not sure if I am that someone mentioned. In case I am - I'd like to clarify 
> what I meant;
>
> Without a version change for the tree-walk, I think we (Google) would need to 
> support both approaches (the old one plus the tree-walk) and based on what we 
> see - make a best guess which version we should use.
> Having two explicit versions still means we have two implementations, but at 
> least we don't have to guess which one to use whenever there would be 
> ambiguity with a single version.
>
> I'm always concerned about what bad people do to gain an advantage. But in 
> this case I'm more worried about somebody having an ambiguous DMARC setup 
> where VLMPs end up guessing the wrong intention. The most likely outcome 
> there would be rejected emails and an upset sender the VLMP need to deal 
> with. But atleast they are not spoofed. I think explicit versioning helps 
> mitigate that risk too (but it wont help companies making bad configurations 
> - but that we always have to live with).
>
> /E
>
> On Thu, Jun 8, 2023 at 10:21 AM John Levine  wrote:
>>
>> It appears that Tobias Herkula   said:
>> >However, such a fundamental shift in the protocol's architecture warrants a 
>> >clear signifier. I suggest we upgrade
>> >our DMARC version string from the current state to 'DMARC2.' This upgrade 
>> >would not only denote the change of SPF
>> >removal, but also the switch from the Public Suffix List (PSL) to the 
>> >Tree-Walk algorithm.
>>
>> I was talking with someone from a Very Large Mail Provider who told me that
>> if we keep the same version number, they won't change what they do now, so
>> no tree walk even if we keep SPF.
>>
>> They understand that as things stand now, the results of the PSL and
>> the tree walk are in practice the same. Their concern is that if some
>> people do it the old way and some the new, and you can't tell which
>> the domain expects, bad guys will create records with deliberately
>> inconsistent results.
>>
>> I'm not sure how likely that is, but arguing with a gorilla rarely
>> turns out well.  I will see if I can talk to people at other VLMPs
>> and see how widespread this concern is.
>>
>> R's,
>> John
>>
>> PS: If we do bump the version number, it needs to go into the
>> aggregate reports, too.
>>
>> ___
>> 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] version bump to DMARC2

[Emil Gustafsson]

Not sure if I am that someone mentioned. In case I am - I'd like to clarify
what I meant;

Without a version change for the tree-walk, I think we (Google) would need
to support both approaches (the old one plus the tree-walk) and based on
what we see - make a best guess which version we should use.
Having two explicit versions still means we have two implementations, but
at least we don't have to guess which one to use whenever there would be
ambiguity with a single version.

I'm always concerned about what bad people do to gain an advantage. But in
this case I'm more worried about somebody having an ambiguous DMARC setup
where VLMPs end up guessing the wrong intention. The most likely outcome
there would be rejected emails and an upset sender the VLMP need to deal
with. But atleast they are not spoofed. I think explicit versioning helps
mitigate that risk too (but it wont help companies making
bad configurations - but that we always have to live with).

/E

On Thu, Jun 8, 2023 at 10:21 AM John Levine  wrote:

> It appears that Tobias Herkula   said:
> >However, such a fundamental shift in the protocol's architecture warrants
> a clear signifier. I suggest we upgrade
> >our DMARC version string from the current state to 'DMARC2.' This upgrade
> would not only denote the change of SPF
> >removal, but also the switch from the Public Suffix List (PSL) to the
> Tree-Walk algorithm.
>
> I was talking with someone from a Very Large Mail Provider who told me that
> if we keep the same version number, they won't change what they do now, so
> no tree walk even if we keep SPF.
>
> They understand that as things stand now, the results of the PSL and
> the tree walk are in practice the same. Their concern is that if some
> people do it the old way and some the new, and you can't tell which
> the domain expects, bad guys will create records with deliberately
> inconsistent results.
>
> I'm not sure how likely that is, but arguing with a gorilla rarely
> turns out well.  I will see if I can talk to people at other VLMPs
> and see how widespread this concern is.
>
> R's,
> John
>
> PS: If we do bump the version number, it needs to go into the
> aggregate reports, too.
>
> ___
> 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] DMARC2 & SPF Dependency Removal

[Alessandro Vesely]

On Fri 09/Jun/2023 16:07:07 +0200 Murray S. Kucherawy wrote:
And signing software shouldn't be mutating messages ever (other than adding 
signatures, of course).



Section 5.3, Normalize the Message to Prevent Transport Conversions, gives 
different advice.  UTF-8, though, seems to be subject to mutating fashions; 
conversion to 7-bit form, IMHO, makes sense only if it is base64.  Quoted 
printable is messy and prevents recovery after MLM transformation.



Best
Ale
--





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

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

[Alessandro Vesely]

On Fri 09/Jun/2023 11:14:29 +0200 Barry Leiba wrote:

One case I saw multiple times where DKIM fails while SPF verifies is when the
message contains a line starting with "from " which some agent changes to
">from ".  Some signing software eliminates such lines before signing, but
that's not in the spec, so one cannot say a signer is defective if it doesn't
do it.


Have you seen that happen in the MTA relay process (in transit), or
only after final delivery?  I can see that an MDA or a recipient MUA
might do that, but it should *not* happen in transit, so it shouldn't
affect DMARC processing.  Do you have actual examples where an MTA is
making that change and breaking the DKIM sig?



I recall it was a problem, which is why I coded the replacement (I add a space, 
not a '>').  In the early years, DKIM suffered mime-autoconversions that many 
MTA were applying just for fun.  And there were some other corner cases that 
now defeat my recollection.


Anyway, having a second string at one's bow is not a defect, unless it's set up 
in a defective way.  But also DKIM can be misconfigured, which is not a good 
reason to eliminate it.  Having both increases the chances of success.



Best
Ale
--




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

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

[Scott Kitterman]

On Friday, June 9, 2023 4:33:54 AM EDT Barry Leiba wrote:
> I think, Scott, that you and I have a fundamental disagreement that's
> not resolvable, and I won't just repeat what I've already said.  But a
> couple of the things you said are ones I can't make sense of, so I'll
> 
> talk about those:
> > Software engineering isn't a perfect science.  In general, a more
> > complex protocol will suffer more defects.  If you want to design
> > things that only work when software is perfect, I'm not interested.
> 
> It seems that you're saying you're "not interested" in any protocol
> that won't work if there's a software bug, and that makes no sense to
> me.  Crypto is hard to get right and there are often bugs; TLS won't
> work if you don't get the crypto right: does that mean you're not
> interested in TLS?  Or VPNs (IPsec)?  Are you not interested in TCP
> because it will fail if there's a bug in the network stack?  For that
> matter, a router with a bug in its MPLS implementation won't work:
> should we not use MPLS?  And, well, if there's a bug in your
> SPF-record parser, SPF won't work either, n'est-ce pas?
> 
> Of course, the level of failure in any of this depends upon just what
> the bug is.

Thanks for pushing back on this.  It was poorly worded.  Let me try again, see 
below.

> > One could make the opposite argument too, and I think it would be
> > equally valid:
> > 
> > The only value DKIM brings for DMARC is for indirect mail flows.  For
> > any direct connections, SPF is sufficient.  All the proposed DKIM
> > changes to solve the DKIM replay problem are likely to break indirect
> > mail flows anyway, so there's no longer a point to keep DKIM.  It's
> > much more complicated and it looks like the benefit of it is going
> > away, let's just simplify the protocol and get rid of it.
> 
> This also makes no sense, as it completely misrepresents the situation
> I'm raising.  It *doesn't* work both ways, because DKIM works in all
> situations that SPF does, but it *also* works in some situations where
> SPF fails.  The opposite is not true.  DKIM adds value beyond what SPF
> does.  SPF does not add value, ever.
> 
> You and Mike seem to be holding on to SPF because you want to, with
> some vague "I've seen network errors and software errors" statements
> but without real arguments.  The only real argument I've seen is
> Seth's about broader deployment of SPF without DKIM.  I've already
> said why I think that's not a reason we should keep SPF, but at least
> that is a reason I can make sense of.

It's not a case of I've seen a few failures, it's consistent (all I can say 
for certain is that it was as I no longer have access to this data).  It was 
consistent across time and providers.  At scale, DKIM would always have a 
fraction of a percent failure rate, while SPF would not (for direct 
connections - I have no disagreement with your statement that SPF doesn't help 
with indirect mail flows).  This probably exculpates DNS as a source of the 
DKIM failures, since I think it's not likely that SPF records could be 
retrieved when DKIM key records could not, but I don't know for sure.

The leads to a situation where the DMARC pass rate for direct connections 
would vary depending on if SPF was included:

DKIM only: ~99.5%
DKIM + SPF: ~100%
SPF only: ~100%

You may not think that last half of a percent is important (my recollection is 
that it varied a bit between 0.2% and 0.8%), but I think it exists and is 
important.

The point I was attempting (badly) to make is that I have seen data that's 
contrary to your claim that there is no case where SPF will enable a DMARC 
pass that DKIM would not also yield a DMARC pass, so we don't need it.  My 
judgement is that you are assuming too much perfection out of DKIM and the 
data doesn't support it.

Does that make more sense?

Scott K




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

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

[Murray S. Kucherawy]

On Fri, Jun 9, 2023 at 2:14 AM Barry Leiba  wrote:

> > One case I saw multiple times where DKIM fails while SPF verifies is
> when the
> > message contains a line starting with "from " which some agent changes to
> > ">from ".  Some signing software eliminates such lines before signing,
> but
> > that's not in the spec, so one cannot say a signer is defective if it
> doesn't
> > do it.
>
> Have you seen that happen in the MTA relay process (in transit), or
> only after final delivery?  I can see that an MDA or a recipient MUA
> might do that, but it should *not* happen in transit, so it shouldn't
> affect DMARC processing.  Do you have actual examples where an MTA is
> making that change and breaking the DKIM sig?
>

My impression is that this translation (from "From " to ">From " and back)
is only supposed to happen at the endpoints.  If done properly, the
signature would be generated after the translation on egress and verified
prior to the translation on ingress.  DKIM is supposed to be executed
against the content that will be "on the wire".  If it's being done in
flight, something is broken.

And signing software shouldn't be mutating messages ever (other than adding
signatures, of course).

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

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

[Barry Leiba]

> One case I saw multiple times where DKIM fails while SPF verifies is when the
> message contains a line starting with "from " which some agent changes to
> ">from ".  Some signing software eliminates such lines before signing, but
> that's not in the spec, so one cannot say a signer is defective if it doesn't
> do it.

Have you seen that happen in the MTA relay process (in transit), or
only after final delivery?  I can see that an MDA or a recipient MUA
might do that, but it should *not* happen in transit, so it shouldn't
affect DMARC processing.  Do you have actual examples where an MTA is
making that change and breaking the DKIM sig?

I would be surprised, but, well, I've been surprised many times by
what email software will do.

> What I find nonsensical is to eliminate SPF in order to save DNS queries, 
> given
> that we replaced local PSL lookups with a series of queries.  We cannot do 
> that
> and pretend that SPF is too expensive.

Yes, I agree: the DNS query load is not one of the arguments I'm making.

Barry

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

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

[Alessandro Vesely]

On Thu 08/Jun/2023 16:44:14 +0200 Barry Leiba wrote:
See, I don't look at it as "harmed".  Rather, I think they're using "we use 
SPF" as a *reason* not to use DKIM, and I think that *causes* harm.



Does that mean SPF is easier to enter than DKIM?  Maybe.  It can be an 
advantage, though.



SPF is, as I see it, worse than useless, as it adds no value to domain that use 
DKIM -- any time DKIM fails SPF will also fail -- and actually impedes the 
adoption of DKIM.



I agree SPF is too much bloated by some providers, to the point that 
impersonation with dmarc=pass can be achieved programmatically.  However, I'd 
rather counter this using an extra spf=no tag, than v=DMARC2.  (Furthermore, 
I'd specify such extra tag in a separate document, not dmarcbis.)


One case I saw multiple times where DKIM fails while SPF verifies is when the 
message contains a line starting with "from " which some agent changes to 
">from ".  Some signing software eliminates such lines before signing, but 
that's not in the spec, so one cannot say a signer is defective if it doesn't 
do it.


What I find nonsensical is to eliminate SPF in order to save DNS queries, given 
that we replaced local PSL lookups with a series of queries.  We cannot do that 
and pretend that SPF is too expensive.



Best
Ale
--





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

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

[Barry Leiba]

Repeating this one point as chair, to make it absolutely clear:

The proposal we're discussing is removing SPF authentication from
DMARC evaluation *only*.  We will *not* consider what should happen to
SPF outside of DMARC, and any discussion of that is *out of scope* for
this working group under its current charter.

Barry, as chair

On Fri, Jun 9, 2023 at 9:39 AM Barry Leiba  wrote:
>
> Thanks for some data, Doug.  One comment on what's after the data
> (still talking as a participant here):
>
> > We have two topics intermixed:  (a) should we deprecate SPF for DMARC 
> > purposes, and (b) should we
> > deprecate SPF completely.   We should definitely not deprecate SPF 
> > completely.
>
> I am certainly not intermixing these!  I agree with you that we should
> *not* deprecate SPF at this time.  I am *only* supporting that we
> remove its use in the standards-track version of DMARC, and that's all
> this working group has scope to do anyway, according to our charter.
> And, yes, a recipient that uses DMARC with DKIM only... is quite free
> to *also* consider SPF in its decision about handling the message...
> just (if we do this) not as part of the DMARC evaluation.
>
> Barry

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

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

[Barry Leiba]

I think, Scott, that you and I have a fundamental disagreement that's
not resolvable, and I won't just repeat what I've already said.  But a
couple of the things you said are ones I can't make sense of, so I'll
talk about those:

> Software engineering isn't a perfect science.  In general, a more
> complex protocol will suffer more defects.  If you want to design
> things that only work when software is perfect, I'm not interested.

It seems that you're saying you're "not interested" in any protocol
that won't work if there's a software bug, and that makes no sense to
me.  Crypto is hard to get right and there are often bugs; TLS won't
work if you don't get the crypto right: does that mean you're not
interested in TLS?  Or VPNs (IPsec)?  Are you not interested in TCP
because it will fail if there's a bug in the network stack?  For that
matter, a router with a bug in its MPLS implementation won't work:
should we not use MPLS?  And, well, if there's a bug in your
SPF-record parser, SPF won't work either, n'est-ce pas?

Of course, the level of failure in any of this depends upon just what
the bug is.

> One could make the opposite argument too, and I think it would be
> equally valid:
>
> The only value DKIM brings for DMARC is for indirect mail flows.  For
> any direct connections, SPF is sufficient.  All the proposed DKIM
> changes to solve the DKIM replay problem are likely to break indirect
> mail flows anyway, so there's no longer a point to keep DKIM.  It's
> much more complicated and it looks like the benefit of it is going
> away, let's just simplify the protocol and get rid of it.

This also makes no sense, as it completely misrepresents the situation
I'm raising.  It *doesn't* work both ways, because DKIM works in all
situations that SPF does, but it *also* works in some situations where
SPF fails.  The opposite is not true.  DKIM adds value beyond what SPF
does.  SPF does not add value, ever.

You and Mike seem to be holding on to SPF because you want to, with
some vague "I've seen network errors and software errors" statements
but without real arguments.  The only real argument I've seen is
Seth's about broader deployment of SPF without DKIM.  I've already
said why I think that's not a reason we should keep SPF, but at least
that is a reason I can make sense of.

Barry

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