Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

[Hector Santos <[e-mail]>]

On 4/26/2023 7:21 AM, Scott Kitterman wrote:
> On April 26, 2023 8:08:39 AM UTC, Alessandro Vesely<[e-mail]>  wrote:
>> On Tue 25/Apr/2023 20:27:18 +0200 Scott Kitterman wrote:
>>> My recollection is that a general formulation that I proposed had at least
>>> some traction out of both groups:
>>>
>>>> [some appropriate description] domains MUST NOT publish restrictive DMARC
>>>> policies due to interoperability issues
>>> Leaving aside (for now) the question of what goes into [some appropriate
>>> description] and with the assumption that there will be some non-normative
>>> discussion to amplify whatever that is and probably give some indication about
>>> what domains might do to not be one of those domains, is there anyone who just
>>> can't live with that formulation of the situation?
>> Me, for one.  Because more than 98% of domains are going to fall into the description, however we word it, that statement makes the whole I-D nonsensical.  Cannot we just tell the problem without MUSTard?
>>
>> In any case, using the complement of [some appropriate description] is certainly easier.  For example:
>>
>>     Forcing authentication into Internet mail by publishing restrictive DMARC
>>     policies breaks some well established patterns of usage.  Publishing such
>>     policies is thus RECOMMENDED only for domains [in this other appropriate
>>     description].
>>
> Thanks.
>
> I understand your objection to be that the proposed description of the interoperability problems would apply to too many domains, regardless of the modifier we might use.  Is that correct?
>
> I don't understand the technical issue associated with that objection.  I get that you feel the construction is too negative, but I don't have a sense you think it's inaccurate.  Focusing on the technical aspects of this, would you please help me understand what you think is technically incorrect about it?
>
> Scott K

Scott,

I will two to remained focus. With Barry's MUST NOT text and as you 
surmised:

    [some appropriate description] domains MUST NOT publish 
restrictive DMARC
    policies due to interoperability issues

I believe you are asking if this is technically correct ...  for IETF 
PS passage?

To me, there were a number of folks who indicated support for MUST NOT 
but preferred more details.

We will need to deal with the consequences when existing restrictive 
domains have the proverbial "book" thrown at them for their user's 
actions which creates the necessary known mitigations;  Rewrite and 
Subscription/Submission controls.  As advice to MLS/MLM 
implementators, the latter should be a natural part of the protocol 
when honoring the policy. The former is a security tear down when 
intentionally not honoring the policy.

With no deliberation as to what the interop issues are and the 
mitigation, not closing the loop holes for implementators, I see a new 
potential security issue is highlighted. The "MUST NOT due to Interop 
issues" may require a security review with a new possible Security 
Section 11.9 "Intentional DMARC Security Tear down Threats" or it may 
fall under an updated section 11.4 as a Display Name Attack.

So is it technically correct and sufficient?

I would be flabbergasted if this was IETF/IESG "technically correct" 
as a PS.  Maybe as an Informational Status, but difficult as a PS and 
I believe Barry may have suggested that.  I agree with that if left as is.


--
HLS