On October 28, 2023 12:01:05 PM UTC, Alessandro Vesely <[email protected]> wrote:
>On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote:
>> On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
