On April 26, 2023 3:24:58 PM UTC, Hector Santos
<hsantos=40isdg....@dmarc.ietf.org> wrote:
>
>
>On 4/26/2023 7:21 AM, Scott Kitterman wrote:
>> On April 26, 2023 8:08:39 AM UTC, Alessandro Vesely<ves...@tana.it> 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
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
