Re: [dmarc-ietf] Add MLS/MLM subscription/submissions controls to DMARCbis

[Douglas Foster <[e-mail]>]

Yes, I think there is value in recommending a specific rewrite format, and
recommending that the unmodified From be stored in an ORIGINAL-FROM:
header.   This solves the user problem, but does not provide feedback to
the list.

About feedback options:

A feedback mechanism could be public or private.   A public mechanism would
presumably be in DNS, to indicate support for a particular technique.  As
applied to the methods mentioned:

- Evaluator whitelisting is specific to a message source, so it is only
suitable for private communication.

- Public notice of ATSP participation provides certainty.  Accepting the
protocol means accepting valid signatures from the third party on behalf of
the first party.   A public assertion of participation also seems to
present no particular increase in risk to the evaluator.

- ARC does not provide certainty, since the interpretation of any single
ARC set depends on the trust given to the ARC set creator, and the specific
content of the ARC set in a particular message.    Therefore, I don't see
that public disclosure of ARC participation can provide the list with the
information that it needs.   So ARC feedback needs to be private.

There has been some talk of providing a version of DMARC reports to senders
when they are different from the domain owners.   It would be a form of
private notification, if all of the objections are overcome and deployment
is sufficiently widespread.

Doug Foster


On Sun, Apr 30, 2023 at 10:25 PM Emanuel Schorsch <[e-mail]>
wrote:

> I want to ask about the "hollow victory" aspect and what would turn it
> into a more meaningful victory. If fromHeader rewriting is the damage we
> want to avoid it seems there's two options:
> 1) Have the mailingList make a decision based on what they know about the
> evaluator. This would need some mechanism for evaluators to indicate what
> trust techniques they accept.
> 2) Have the mailingList rewrite the fromHeader but store the original
> fromHeader and propagate the necessary trust information so that downstream
> evaluators can undo the rewriting.
>
> Given that currently many mailingList do fromHeader rewriting it seems
> that #2 would allow gradual adoption and flexibility for experimentation
> over time to see what trust methods work and allow downstream evaluators to
> make personalized decisions depending on the recipients trust preferences.
>
> What are your thoughts? What would be needed for that to result in a
> non-hollow victory?
>
>
> On Sun, Apr 30, 2023, 9:54 PM Douglas Foster <
> [e-mail]> wrote:
>
>> Everything depends on an evaluator who trusts the alternate
>> authentication protocol.   We have at least three trust techniques:
>> - local policy at evaluator
>> - ARC set trusted by evaluator
>> - ATPS trusted by evaluator.
>>
>> Until the list knows that the evaluator will accept the credentials, he
>> has to assume that rewrite is necessary to avoid message blocks,
>> unsubscribes, and possibly blacklisting
>>
>> No such feedback exists at present, so even though ARC has some
>> acceptance, it is a hollow victory.
>>
>> DF
>>
>>
>> On Sun, Apr 30, 2023, 8:05 PM Hector Santos <[e-mail]> wrote:
>>
>>>
>>>
>>> On Apr 29, 2023, at 4:42 PM, Douglas Foster <
>>> [e-mail]> wrote:
>>>
>>> ...
>>>
>>> But I need to clarify whether I understand your point.   What I am
>>> hearing is:
>>>
>>>    - For the short term, mailing lists should refuse postings from
>>>    DMARC-enforcing domains.   That position can be relaxed only if all
>>>    participating domains have agreed to ignore DMARC Fail for messages from
>>>    the list  (Ale floated some ideas about that approach.)
>>>    - For the longer term, we need a non-DKIM method for delegating
>>>    rights to a third party.
>>>
>>>
>>> Ideally, the goal is to eliminate “From Rewrite” to return to the “good
>>> ol’ days.”  So the first time is to recognize having subscription and
>>> submissions controls is a natural consideration for the DKIM Policy
>>> "Protocol Complete” model. If the MLS supports the protocol, it would
>>> consider this method more so than a destruction method that tear down
>>> security.  This will also pass the buck back to the domain owner to deal
>>> with its user’s needs or not.
>>>
>>> You talk about "incomplete protocol" as if this is a commonly understood
>>> and accepted term.  I interpret it to mean a third-party authentication
>>> method other than DKIM.  DKIM does serve for third-party authentication
>>> where it has been embraced and deployed.   So the issue is that it has not
>>> been practical for many situations and we do need another option.
>>>
>>>
>>> Protocol complete is a client/server protocol negotiation concept.  It
>>> basically means the “State Machine”, the conversation between the client
>>> and server is well-defined. No Loop Holes!!!! Very key concept in protocol
>>> design.
>>>
>>> In terms of DKIM Signing Practices, you can read "Requirements for a
>>> DomainKeys Identified Mail (DKIM) Signing Practices Protocol https
>>> ://www.rfc-editor.org/rfc/rfc5016.txt
>>> <https://www.rfc-editor.org/rfc/rfc5016.txt> for its definition.
>>>
>>> DKIM Signing Complete: a practice where the dtomain holder assert
>>> that all legitimate mail will be sent with a valid first party
>>> signature.
>>>
>>> But I believe it is not Protocol Complete and to achieve this with DKIM
>>> Policy Modeling, you have to cover the other signing scenarios which
>>> includes 3rd party signing scenarios.
>>>
>>> ATPS is the best we got and it works. You don’t have to worry, You are
>>> using gmail.com. Relaxed policy. Minimal security. ietf.org Rewrite
>>> destroys my isdg.net domain security even though I have ietf.org
>>> authorized as an ATPS signer.
>>>
>>> It should honor policy and reject my submissions. Idea. Add the option
>>> to the subscription. If you don’t care, let it rewrite to join or use
>>> another unsecured address.
>>>
>>> Not hard.
>>>
>>> —
>>> HLS
>>>
>>>
>>> _______________________________________________
>> dmarc mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
>