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

[Scott Kitterman <[e-mail]>]

On April 26, 2023 3:24:58 PM UTC, Hector Santos <hsantos=[e-mail]> wrote:
>
>
>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.
>

I agree that more will be needed.  Thanks for the feedback.  The last run at this question ended up being a mess, so I'm trying to see if we can get further by going in small steps.

Scott K