On March 17, 2024 11:11:04 AM UTC, Alessandro Vesely <ves...@tana.it> wrote:
>On Sat 16/Mar/2024 20:01:22 +0100 Scott Kitterman wrote:
>> On Thursday, March 14, 2024 12:24:50 PM EDT Scott Kitterman wrote:
>>> On Thursday, March 14, 2024 11:44:22 AM EDT Todd Herr wrote:
>>>>
>>>> Issue 135 is open for the subject topic. Please add your thoughts to this
>>>> thread and/or to the issue in Github.
>>>>
>>>> Thank you.
>>>
>>> [...]
>>>
>>> I think both of these should be addressed as part of this issue in Security
>>> Considerations.
>>
>> It seems to me that, to the extent we are going to address this issue, there
>> is agreement that Security Considerations is appropriate. Here's proposed
>> text:
>>
>> 11.X External Mail Sender Cross-Domain Forgery
>>
>> Both of the email authentication methods which underlie DMARC fundamentally
>> provide some degree of assurance that an email was transmitted by an MTA
>> which
>> is authorized to do so. SPF policies just map domain names to sets of
>> authorized MTAs [ref to RFC 7208, section 11.4]. Verified DKIM signatures
>> indicate that an email was transmitted by an MTA with access to a private key
>> that matches the published DKIM key record.
>>
>> When Domain Owners authorize mail to be sent by sources outside their
>> Administrative Management Domain there is a risk that an overly permissive
>> source may send mail which will, as a result, receive a DMARC pass result
>> that
>> was not, in fact, authorized by the Domain Owner. These false positives may
>> lead to issues with systems that make use of DMARC pass results to indicate a
>> message is in some way authentic. They also allow such unauthorized senders
>> to evade the Domain Owner's requested message handling for authentication
>> failures.
>>
>> The only method to avoid this risk is to ensure that no overly permissive
>> sources can successfully DKIM sign the domain's mail or transmit mail which
>> will evaluate as SPF pass. If there are non-DMARC reasons for a domain owner
>> to include a permissive source in a domain's SPF record, the source can be
>> excluded from DMARC consideration by using the '?' qualifier on the SPF
>> record
>> mechanism associated with that source.
>
>
>That text is too long and lacks an example.
>
>The first paragraph can be omitted without losing context. BTW, Section 11.4
>of RFC 7208 is about /cross-user/ forgery, not cross-domain.
>
>The second paragraph doesn't mention SPF. Couldn't it be more direct? For
>example:
>
> Domain Owners who set up SPF records which include sources outside their
> Administrative Management Domain run the risk that an overly permissive
> source may allow its users to send scam mail which will receive a DMARC
> pass results that were not intended by the Domain Owner. These false
> positives [...]
>
>The third paragraph is also longer than needed. There's no need to mention
>DKIM if we're talking SPF forgery. I'd also point out that the neutral
>qualifier prevents quick rejection of the message, and is probably useless for
>those who have ~all. (Are there MTAs who distinguish between neutral and
>softfail? Are we prompting them to do so?) Perhaps mention that this is a
>compromise between striking the SPF record tout-court and allowing false
>positives.
>
>Most important, write "?include:example.com". An example is worth a thousand
>words.
I disagree.
Security considerations should be a complete description of the consideration.
While the data that's been discussed about current issues has been SPF related,
there's no reason a third-party couldn't equally screw up and sign DKIM in a
similar manner. We should include both (we discussed this pretty extensively
already, let's not do it again).
I think we need to be explicit that there are two risks:
1. Bad mail gets DMARC pass and so DMARC policy is not applied (avoid
consequences of DMARC fail).
2. Bad mail gets DMARC pass and something else (e.g. BIMI) does a wrong thing
(gets benefits of DMARC pass).
It's not typical to put examples in security considerations. Additionally, I
think doing so would over emphasize that aspect of the consideration. We're a
technical group and so we like technical solutions, but for this one, I think
the boring and difficult policy question of not authorizing third parties that
do bad things is more important.
Scott K
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
